Redshift zero-ETL: how it works, supported sources, limitations, pricing and history mode

What is Redshift zero-ETL?

Zero-ETL is an AWS feature that continuously replicates tables from a source system into Amazon Redshift without you building or operating a pipeline. You create an integration, AWS performs an initial full load and then keeps the Redshift copy current as the source changes. There is no extract job to schedule, no connector to configure, no replication instance to size, and nothing to restart when it fails.

The name is slightly misleading. The extract and load still happen, they are just operated by AWS instead of by you or a vendor. What genuinely disappears is the transform step in the middle: zero-ETL does not support transformations while replicating, so the shape that lands in Redshift is the shape the source had.

How does AWS Redshift zero-ETL work?

On activation the integration exports the full source table set to populate the Redshift database, then switches to incremental replication. The replicated tables land in a database created from the integration, and they carry a state. By default you can query only the tables in the Synced state, which is a detail worth knowing before you conclude that a table is missing.

You control the cadence with REFRESH_INTERVAL, set on the database with CREATE DATABASE or ALTER DATABASE. It can slow replication down, which is sometimes what you want for cost reasons, but it cannot push latency below the documented floor for the source type.

Which sources support zero-ETL to Redshift?

Zero-ETL integration sources for Amazon Redshift, with latency, filtering support and constraints

Source	Latency	Data filtering	What to know
Aurora MySQL	Near real time	Yes, table filters	The original zero-ETL source. Tables need a primary key
Aurora PostgreSQL	Near real time	Yes, table filters	Generally available since 15 October 2024, on Aurora PostgreSQL 16.4 and higher. Redshift supports a maximum of 100 databases from one Aurora PostgreSQL source
RDS for MySQL	Near real time	Yes, table filters	Same primary key requirement as Aurora
DynamoDB	Minimum 15 minutes	No	Data maps to the SUPER type. An individual attribute must not exceed 64 KB, and table or key names over 127 characters are unsupported
Salesforce, SAP, ServiceNow, Zendesk	Minimum 1 hour	No	Runs through AWS Glue. Table and column names over 127 characters are unsupported

The Aurora and RDS for MySQL integrations support data filtering, so you can include or exclude specific tables rather than replicating everything. That matters more than it sounds: without filtering, a zero-ETL integration is an all-or-nothing decision about a production schema, and Redshift storage is not free.

Postgres zero-ETL to Redshift

Aurora PostgreSQL zero-ETL integration with Redshift became generally available on 15 October 2024, for Aurora provisioned clusters and Aurora Serverless v2, on Aurora PostgreSQL version 16.4 and higher. One Aurora PostgreSQL source can replicate up to 100 databases into Redshift, each independently.

The important caveat: this is Aurora PostgreSQL, not self-managed PostgreSQL on EC2 and not PostgreSQL running anywhere else. If your Postgres is not Aurora, zero-ETL is not available to you and the realistic options are AWS DMS, a managed connector, or logical replication into something that can load Redshift. The trade-offs there are covered in PostgreSQL ETL tools.

Redshift zero-ETL limitations

This is the section to read before you plan anything, because most of these are structural rather than tunable. Straight from the AWS considerations page:

Amazon Redshift zero-ETL integration requirements and limitations

Rule	What AWS requires
Target must be Serverless or RA3	Redshift Serverless, or a provisioned cluster of an RA3 or RG node type
Encryption required	A provisioned cluster must be encrypted
Case sensitivity required	The target data warehouse must have case sensitivity enabled
Primary keys required	Source tables without a primary key cannot be replicated to Redshift at all
Read-only destination	You cannot create tables, views or materialized views in the destination database
No in-flight transformation	Data is replicated as-is. Transform it afterwards, inside Redshift
50 integrations per warehouse	The documented maximum for a single Redshift target
UTF-8 only	Redshift might not honor the source collation, which can change sorting and query results
VARCHAR caps at 65,535 bytes	Oversized content fails the table unless you set TRUNCATECOLUMNS to TRUE
One Region	Integrations run within a Region, and you cannot create two between the same source and target

Two of these deserve emphasis. The primary key requirement is the one that derails timelines, because a table without a primary key is simply not replicated and nothing tells you loudly. Audit the source schema first with a query like this one:

SELECT t.table_schema, t.table_name
FROM information_schema.tables t
LEFT JOIN information_schema.table_constraints c
  ON  c.table_schema = t.table_schema
  AND c.table_name   = t.table_name
  AND c.constraint_type = 'PRIMARY KEY'
WHERE t.table_type = 'BASE TABLE'
  AND t.table_schema NOT IN ('pg_catalog', 'information_schema')
  AND c.constraint_name IS NULL;

The second is the read-only destination. You cannot create tables, views or materialized views in the database that the integration created. The supported pattern is to build your models in a different Redshift database and query across, using materialized views on the replicated tables from that side.

Redshift zero-ETL pricing

There is no separate per-integration charge for the zero-ETL feature itself. What you pay for is the Redshift capacity the replicated data consumes: storage for the tables and compute for the ingestion and the queries that read them. On Redshift Serverless that shows up as RPU consumption, and on a provisioned cluster it shows up as needing a bigger cluster sooner.

The practical consequence is that the cost question is a capacity question. Replicating an entire production schema because it was one click is how teams end up surprised, which is the real argument for using data filtering to replicate only the tables anyone queries. Because the spend lands inside your existing AWS bill rather than on a separate vendor invoice, it is also easy to miss, and worth watching with the same discipline you apply to the rest of your cloud spend.

Compare that to the metered third-party model, where you pay a vendor per monthly active row or per credit on top of the same Redshift capacity. Zero-ETL removes the vendor layer entirely for the sources it covers, which is why the first question on any Redshift ETL evaluation should be whether zero-ETL covers the source at all.

Redshift zero-ETL history mode

By default the Redshift copy mirrors the current state of the source, so an updated row overwrites the previous version and history is lost. History mode changes that: rows are versioned, with _record_is_active and delete timestamps, so you can query what a record looked like at a point in time. That makes slowly changing dimension reporting possible on replicated data without building the versioning yourself.

The behavior is specific and worth knowing. Dropping a table on the source does not drop it on the target: it moves to the DroppedSource state. Truncating on the source marks the corresponding target rows inactive rather than removing them. A row set to inactive can be deleted after a short delay of about 10 minutes, and you can only delete inactive rows. Turning history mode off saves the historical data to a table named with a _historical_ suffix and a timestamp, and refreshes the original.

What goes wrong, and what to do about it

Common Redshift zero-ETL failures, their cause and the fix

Symptom	Cause	Fix
A table never appears in Redshift, everything else works	That table has no primary key in the source	Add a primary key on the source table, then resync. This is the single most common zero-ETL surprise
A table stops replicating and enters a failed state	A value exceeded the 65,535 byte Redshift VARCHAR ceiling	Set the database parameter TRUNCATECOLUMNS to TRUE so oversized content is truncated rather than fatal
Queries return nothing for a table you can see	By default you can only query tables in the Synced state	Check SVV_INTEGRATION_TABLE_STATE, or set QUERY_ALL_STATES to TRUE to query other states
The whole integration goes to FAILED	The source was deleted, or a cluster or instance was renamed while an integration existed	Previously replicated data stays queryable in Redshift. Recreate the integration against a valid source
Sorting and comparisons differ from the source	Redshift accepts only UTF-8 and might not honor the source collation	Verify any query whose result depends on collation, especially ORDER BY on text and case-sensitive joins
Decimal scale is shorter than in the source	For DynamoDB partition and sort keys the maximum is precision 38 and scale 18, while the Redshift default is 38 and 10	Check the numeric columns you report on and cast explicitly in the models you build on top

Notice the pattern: almost every one of these is quiet. A missing table, a table stuck in a non-Synced state, an integration in a failed state after someone deleted a source. None of them break a dashboard, they just stop updating it, which is the failure mode that survives longest before anyone notices.

When zero-ETL is the wrong tool

Four situations, and they are all structural rather than matters of preference. If you need to mask, hash or drop sensitive fields before the data lands in the warehouse, zero-ETL cannot do it, because there is no transformation step in flight. If your source is not in the supported list, including self-managed PostgreSQL, SQL Server, and most SaaS applications, it is not an option at all. If your source tables genuinely cannot take primary keys, they will not replicate. And if you need the destination database to be writable, for example because your models live in the same database as the raw tables, the read-only constraint rules it out.

In those cases you are back to choosing a mechanism and a vendor, and the honest comparison of that field is on Redshift ETL tools. For continuous replication out of databases with no zero-ETL path, change data capture tools covers the log-based options, and ETL versus ELT explains why landing raw and transforming afterwards became the default order in the first place.

A checklist before you enable an integration

Confirm the target is Redshift Serverless or an RA3 or RG cluster, that it is encrypted, and that case sensitivity is enabled, because retrofitting those on an existing warehouse is the slow part. Run the primary key audit above and fix or accept every table it returns. Decide which tables you actually need and set up data filtering if the source supports it, rather than replicating a whole schema by default. Check the widest text columns in the source against the 65,535 byte Redshift VARCHAR ceiling and decide whether you want TRUNCATECOLUMNS on. Plan where your models will live, given that the destination database is read only. And put an alert on table state, because the thing that will eventually go wrong here is silent.