Working with Aurora zero-ETL integrations with Amazon Redshift

Help you derive holistic insights from multiple data sources.

Eliminate the need to build and maintain complex data pipelines that perform extract, transform, and load (ETL) operations. Zero-ETL integrations remove the challenges that come with building and managing pipelines by provisioning and managing them for you.

Reduce operational burden and cost, and let you focus on improving your applications.

Let you leverage Amazon Redshift's analytics and ML capabilities to derive insights from transactional and other data, to respond effectively to critical, time-sensitive events.

The source DB cluster must be in the same Region as the target Amazon Redshift data warehouse.

You can't rename a DB cluster or any of its instances if it has existing integrations.

You can't delete a DB cluster that has existing integrations. You must delete all associated integrations first.

If you stop the source DB cluster, the last few transactions might not be replicated to the target data warehouse until you resume the cluster.

If your cluster is the source of a blue/green deployment, the blue and green environments can't have existing zero-ETL integrations during switchover. You must delete the integration first and switch over, then recreate it.

A DB cluster must contain at least one DB instance in order to be the source of an integration.

If your source cluster is the primary DB cluster in an Aurora global database and it fails over to one of its secondary clusters, the integration becomes inactive. You must delete and recreate the integration.

You can't create an integration for a source database that has another integration being actively created.

When you initially create an integration, or when a table is being resynchronized, data seeding from the source to the target can take 20-25 minutes or more depending on the size of the source database. This delay can lead to increased replica lag.

Some data types aren't supported. For more information, see Data type differences between Aurora and Amazon Redshift databases.

Foreign key references with predefined table updates aren't supported. Specifically, ON DELETE and ON UPDATE rules aren't supported with CASCADE, SET NULL, and SET DEFAULT actions. Attempting to create or update a table with such references to another table will put the table into a failed state.

ALTER TABLE partition operations cause your table to resynchronize in order to reload data from Aurora to Amazon Redshift. The table will be unavailable for querying while it's resynchronizing. For more information, see One or more of my Amazon Redshift tables requires a resync.

XA transaction aren't supported.

Object identifiers (including database name, table name, column names, and others) can contain only alphanumeric characters, numbers, $, and _ (underscore).

Your source DB cluster must be running Aurora MySQL version 3.05 (compatible with MySQL 8.0.32) or higher.

Zero-ETL integrations rely on MySQL binary logging (binlog) to capture ongoing data changes. Don't use binlog-based data filtering, as it can cause data inconsistencies between the source and target databases.

Aurora MySQL system tables, temporary tables, and views aren't replicated to Amazon Redshift.

Zero-ETL integrations are supported only for databases configured to use the InnoDB storage engine.

Your source DB cluster must be running Aurora PostgreSQL (compatible with PostgreSQL 15.4 and Zero-ETL Support).

You can create and manage zero-ETL integrations for Aurora PostgreSQL only in the Amazon RDS Database Preview Environment, in the US East (Ohio) (us-east-2) AWS Region. You can use the preview environment to test beta, release candidate, and early production versions of PostgreSQL database engine software.

You can create and manage integrations for Aurora PostgreSQL only using the AWS Management Console. You can't use the AWS Command Line Interface (AWS CLI), the Amazon RDS API, or any of the AWS SDKs.

When you create a source DB cluster, the parameter group that you choose must already have the required DB cluster parameter values configured. You can't create a new parameter group afterwards and then associate it with the cluster. For a list of required parameters, see Step 1: Create a custom DB cluster parameter group.

You can't modify an integration after you create it. If you need to change certain settings, you must delete and recreate the integration.

Currently, Aurora PostgreSQL DB clusters that are the source of an integration don't perform garbage collection of logical replication data.

All databases created within the source Aurora PostgreSQL DB cluster must use UTF-8 encoding.

Column names can't contain any of the following characters: commas (,), semicolons (;), parentheses ( ), curly brackets { }, newlines (\n), tabs (\t), equal signs (=), and spaces.

Zero-ETL integrations with Aurora PostgreSQL don't support the following: