When selecting a destination, it’s important to first verify that all the data sources you want to connect to Stitch will be compatible.
As Stitch currently allows only one destination per account, we recommend verifying your integrations’ compatibility before connecting a destination. This will ensure that you can successfully connect and replicate data from all your sources.
Degrees of incompatibility
The compatibility of any integration/destination combination falls into one of three categories: always compatible, sometimes compatible, and never compatible.
The matrices below use the following icons to indicate the degree of incompatibility for an integration/destination combo:
- indicates that, as far as we know, this combo is always compatible.
- indicates that this combo is sometimes compatible - there may be compatibility issues, but they’re infrequent or parts of the integration may still be usable.
- indicates that this combo is never compatible. It’s unlikely that Stitch will be able to load data from this integration into the given destination.
Incompatible integrations by destination type
Below you’ll find a list of integrations that may have full or partial incompatibility with any of Stitch’s destination offerings.
For a comprehensive look at how destinations will load data - including what may cause data to be "rejected" - refer to the Data loading guides.
| Amazon S3 (link) | |||
| No compatibility issues have been discovered between Amazon S3 and Stitch's integration offerings. | |||
| BigQuery (link) | |||
| No compatibility issues have been discovered between BigQuery and Stitch's integration offerings. | |||
| data.world (link) | |||
| No compatibility issues have been discovered between data.world and Stitch's integration offerings. | |||
| Azure SQL Data Warehouse (link) | |||
| No compatibility issues have been discovered between Azure SQL Data Warehouse and Stitch's integration offerings. | |||
| Panoply (link) | |||
| Integration | Integration version | Level | Reason |
| MongoDB | N/A |
As a result of the de-nesting Stitch performs on nested structures, deeply nested data in Mongo may result in tables that exceed Redshift’s 1,600 column limit. |
|
| PostgreSQL (link) | |||
| Integration | Integration version | Level | Reason |
| HubSpot | ANY |
Tables and columns created as a result of the de-nesting Stitch performs on nested structures may have names that exceed PostgreSQL’s limit of 63 characters for tables and 59 characters for columns. PostgreSQL destinations will reject these tables and columns, meaning Stitch will be unable to load them. |
|
| Stripe | ANY |
Tables and columns created as a result of the de-nesting Stitch performs on nested structures may have names that exceed PostgreSQL’s limit of 63 characters for tables and 59 characters for columns. PostgreSQL destinations will reject these tables and columns, meaning Stitch will be unable to load them. |
|
| Redshift (link) | |||
| Integration | Integration version | Level | Reason |
| MongoDB | N/A |
As a result of the de-nesting Stitch performs on nested structures, deeply nested data in Mongo may result in tables that exceed Redshift’s 1,600 column limit. |
|
| Snowflake (link) | |||
| No compatibility issues have been discovered between Snowflake and Stitch's integration offerings. | |||
| Related | Troubleshooting |
Questions? Feedback?
Did this article help? If you have questions or feedback, feel free to submit a pull request with your suggestions, open an issue on GitHub, or reach out to us.