Snowflake Pushes CDC into Postgres Itself
Snowflake released data mirroring in public preview on July 23, 2026. The feature replicates tables from Snowflake Postgres into Snowflake analytics continuously. It needs no external ETL pipelines or connector processes.
The mechanism is a new Postgres extension. It is called snowflake_cdc, and it pushes batches of changes into Apache Iceberg™ tables stored in object storage. Snowflake then applies those batches serverlessly on the analytics side. The extension runs inside the database and writes directly to a change log. No external system polls the write-ahead log.
This is a meaningful shift. Conventional CDC tools read Postgres logical decoding output from outside the database. The external consumer has no direct visibility into schema state or snapshot alignment. It also cannot tell whether a pause is a network fault or a database outage. Those gaps produce fragile pipelines that require careful idempotency design and manual failure recovery.
The snowflake_cdc extension runs inside Postgres. It knows exactly when schema changes occur. It knows how snapshots align with in-flight changes. It coordinates DDL and DML transactions before writing to the change log.
What the Feature Actually Does
Data mirroring runs entirely inside Snowflake. There is no external CDC service to deploy. There is no connector process to operate. Once a mirror is created, Snowflake maintains target tables. Those tables reflect the current state of their Postgres source, including schema changes and newly created tables inside mirrored schemas.
Setup uses a single SQL command, the Snowsight UI, or Snowflake CoCo. The snowflake.postgres.create_mirror procedure takes a mirror name, source instance, source tables or schemas, target database name, and a refresh interval. The target database must not already exist. The mirror creates it automatically.
Two extensions are required: pg_lake and snowflake_cdc. Existing Snowflake Postgres instances created before the mirroring feature was available need an instance refresh before they can use it.
Several specific capabilities are documented.
$live views: Every mirrored table gets a $live view. It combines applied data with in-flight changes. Readers see committed source changes within seconds.
$changes feed: A seven-day change feed exposes inserts, updates, and deletes, queryable from both Snowflake and Postgres.
Transactional consistency: All Snowflake tables advance in one transaction to a Postgres transaction boundary, preserving foreign key integrity across downstream joins.
Schema propagation: DDL changes on the source propagate automatically without reconfiguring the mirror. One documented constraint: tables tracked by snowflake_cdc do not allow ADD COLUMN with a DEFAULT clause. The column must be added first, then populated separately.
Failure recovery: If WAL is dropped unexpectedly, Postgres can automatically push new snapshots and instruct Snowflake to consume them. Snowflake states this is rare in practice due to the use of failover slots.
The underlying transport writes compressed Parquet into per-table change logs and a meta log in Iceberg. The apply process in Snowflake acts as a finite state machine. It processes adjacent change batches together and sequences schema changes correctly, even when DDL and DML occur in the same transaction.
The Business Case in Production
Ericsson consolidated four legacy databases onto Snowflake Postgres. They eliminated sync pipelines that previously carried up to 40 days of lag. Their customer support platform moved from a 48-hour data lag and 12-hour processing times to under an hour end to end.
SimCorp reduced synchronization time by 10x, from several hours to under 20 minutes. That result covers a market ID service that standardizes exchange codes across financial data spanning more than 40 years.
For Ericsson, the source describes eliminating sync pipelines, competing sources of truth, and extra infrastructure. For SimCorp, the source states that Snowflake Postgres removes the need for reconciliation code, streamlining operations and reducing overhead.
Snowflake has stated that Snowflake-to-Postgres mirroring is coming later this year, which would enable bidirectional sync. That capability is not yet available. The announcement does not state a GA date for either direction.
What Data Platform Architects Should Evaluate
The critical prerequisite is clear. Data mirroring requires a Snowflake Postgres instance, not a self-hosted Postgres database, an Amazon RDS instance, or another managed Postgres service. Teams running Postgres outside Snowflake cannot use this feature as described.
For those cases, a logical replication path to migrate an existing Postgres database into Snowflake Postgres is documented, but it is a separate workstream.
For teams already on or considering Snowflake Postgres, these are the bounded questions worth answering before committing to a pilot.
Consistency requirements. The $live view delivers sub-minute latency on committed changes. If your downstream models depend on exact transaction boundaries across multiple tables, verify that your current pipeline handles this correctly. Measure whether the mirroring behavior matches or improves it.
DDL handling. Schema changes propagate automatically. But the ADD COLUMN constraint means you cannot include DEFAULT values inline. Audit any migration scripts or ORM-generated DDL that uses ADD COLUMN with a DEFAULT. Adjust before enabling mirroring.
Refresh interval and cost. The create_mirror procedure takes a configurable refresh interval. The evidence does not state the minimum supported interval or how compute cost scales with interval frequency. Clarify this with Snowflake before sizing a production workload.
Preview status. Postgres Mirror features are in preview and under rapid development. Some features may not be available. Treat current behavior as subject to change. Avoid hard production dependencies until general availability is confirmed.
Pilot metrics. Define success criteria before testing. Measure replication lag at your peak write volume. Track DDL propagation time for your most common schema changes. Test behavior on failure and restart. Calculate total compute cost per GB replicated. Compare those numbers against your existing pipeline's cost and incident rate.