Stitch Documentation
has moved!

Please update your bookmarks to

If you're not automatically redirected after 5 seconds, click here.

Redshift Destination Overview

Amazon Redshift is fully managed, cloud-based data warehouse. Redshift exhibits far better performance for large-scale analytical queries than do traditional, row-based relational databases like MySQL or PostgreSQL. You can learn more about transactional vs. analytic databases in our Data Strategy Guide.

While Redshift is based on Postgres and therefore shares many similarities, there are some key differences. 

Table & Column Name Length Restrictions

Unlike Postgres which has a limit of 63 characters for names, Redshift supports lengthier table and column names:

  • Table names can contain up to 127 characters. Stitch will not replicate tables with names longer than this.
  • Column names can contain up to 115 characters. Stitch reserves the last 12 characters for renaming columns in the case of data type collisions. In this scenario, Stitch will split the column into multiples, one for each data type.

Primary Keys

Stitch uses Primary Keys in the replication process as the key indicator of rows to add and/or update. 

Redshift has a relatively cosmetic implementation of Primary Keys, meaning their usage isn't enforced in any way. Stitch uses table comments to store Primary Key information for use in the replication process.

Case Insensitivity

Redshift is case insensitive, meaning that tables and columns that differ only in case will result in collision errors. For example: columns named id and Id will result in a collision.

Nested Data Structures

Redshift doesn't natively support nested record replication and storage. To compensate for this, Stitch will de-nest nested records and break them into subtables for easier querying.

Click here for more info on how Stitch handles nested structures in Redshift.


When timestamp data arrives in Redshift, Redshift will convert those timestamps into UTC and display the data type as TIMESTAMP WITHOUT TIME ZONE

Views with Dependencies

Views are incredibly useful tools for filtering out unnecessary data from database tables. While you're free to build views on top of the integration tables created by Stitch, you may occasionally encounter "dependency" errors.

This issue is typically a result of how Stitch handles altered table structures and views with dependencies. Stitch won't automatically drop views with dependencies, as we don't want to affect your work without your say-so.

Click here for more info on how Stitch handles views with dependencies.

Data Loading Scenarios

Because data can come from a variety of integrations and all those integrations may structure or handle data differently, Stitch will likely encounter numerous scenarios when replicating and loading your data. It's important to familiarize yourself with how certain scenarios will be handled so you can understand what's happening or how to diagnose an issue.

Click here for more info on what those scenarios are and how Stitch handles them.

Was this article helpful?
0 out of 0 found this helpful


Questions or suggestions? If something in our documentation is unclear, let us know in the comments!