Stitch Documentation
has moved!

Please update your bookmarks to

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

Postgres Beta Destination Overview

Please note that our Postgres destination is currently in open beta. The information in this article is subject to change.

Beta Guidelines

Currently the Stitch Postgres destination is in open beta. We encourage you to participate and give us feedback, but please consider the following first:

  1. Because Postgres is currently in beta, you may encounter bugs or other unexpected effects while using it.
  2. There may be situations where re-replicating your data is necessary to correct issues.

We appreciate your patience and feedback as we work to perfect this destination.

Connecting a Postgres Destination

When it comes to setting up, hosting, and connecting Stitch to a Postgres destination, you have a few options:

Key Concepts for Working with Postgres

The Stitch Postgres destination integration shares a lot of similarities with our Redshift integration, but there are several key differences to keep in mind.  

Table & Column Name Length Restrictions

Standard Postgres installations support table and column name lengths up to 63 characters. Unlike Amazon Redshift - which is based on Postgres and supports names up to 128 characters - this will lead to more situations where replicated data won't fit into Postgres.

  • For table names longer than 63 characters, Stitch will NOT replicate the table into Postgres
  • For column names longer that 59 characters, Stitch will drop the offending column but replicate all other columns in the table that are under the character limit.

    Stitch reserves the last 4 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. The standard installation of Postgres supports actual Primary Keys, which Stitch will create and maintain when replicating data to Postgres.

To illustrate the difference between standard Postgres and Redshift implementations, consider how Redshift handles Primary Keys. 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.

Facebook Support

Due to the 63 character limit for table names, Facebook Ads integration support for Postgres is limited. Some of the subtables created as a result of deconstructing the nested structures in Facebook's API will have names that exceed 63 characters. As a result, Stitch won't be able to replicate them into Postgres.

We're working on releasing a version of the Facebook Ads integration that works around these limitations. 

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!