Considerations when using zero-ETL integrations with Amazon Redshift

Your target Amazon Redshift data warehouse must meet the following prerequisites:

You can't enable enhanced VPC support on data warehouses with integrations configured.

If you delete a source that is an authorized integration source for an Amazon Redshift data warehouse, all associated integrations will go into the FAILED state.

You can't delete an Amazon Redshift data warehouse that has existing zero-ETL integrations. You must delete all associated integrations first.

You must first delete any integrations that are associated with a destination database before deleting the destination database.

The destination database is read-only. You can't create tables, views, or materialized views in the destination database. However, you can use materialized views on other tables in the target data warehouse.

Materialized views are supported when used in cross-database queries. Refreshing materialized views with data replicated from zero-ETL integrations leads to a full refresh of the view. Incremental refresh, automatic query rewriting, autorefresh, and automated materialized views are not supported. For information about creating materialized views with data replicated through zero-ETL integrations, see Creating materialized views with replicated data.

You can query tables only in the target data warehouse that are in the Synced state. For more information, see Metrics for zero-ETL integrations.

Amazon Redshift accepts only UTF-8 characters, so it might not honor the collation defined in your source. The sorting and comparison rules might be different, which can ultimately change the query results.

The maximum length of an Amazon Redshift VARCHAR data type is 65,535 bytes. When the content from the source does not fit into this limit, replication does not proceed and the table is put into a failed state. For more information about data type differences between zero-ETL integration sources and Amazon Redshift databases, see Data type differences between Aurora and Amazon Redshift in the Amazon Aurora User Guide.

Tables in the integration source must have a primary key. Otherwise, your tables can't be replicated to the target data warehouse in Amazon Redshift.

For Aurora PostgreSQL and RDS for MySQL zero-ETL integrations with Amazon Redshift, create your target data warehouse in Preview. For more information, see Create and configure a target Amazon Redshift data warehouse.

Zero-ETL integration does not support transformations while replicating the data from transactional data stores to Amazon Redshift. Data is replicated as-is from the source data base. However, you can apply transformations on the replicated data in Amazon Redshift.

There can be an impact to other workloads running in Amazon Redshift. To eliminate impact of zero-ETL integration on other workloads, consider using a separate endpoint for zero-ETL integration and share the data with other endpoints that need access to this data using datasharing.

Zero-ETL integration runs in Amazon Redshift using parallel connections. It runs using the credentials of the user who created the database from the integration. When the query runs, concurrency scaling does not kick in for these connections during the sync (writes). Concurrency scaling reads (from Amazon Redshift clients) works for synced objects.

For Aurora sources, see Limitations in the Amazon Aurora User Guide.

For Amazon RDS sources, see Limitations in the Amazon RDS User Guide.