DATABASES Signal 500
How We Pushed CDC into Postgres
↗
Snowflake’s new Data Mirroring feature adds a push-based CDC extension to Postgres that streams batched changes into Iceberg tables on object storage for automatic, transactional replication into Snowflake.
Engineers no longer need to stitch together fragile logical-decoding pipelines or manage separate replication services, which reduces operational overhead and cost. The built-in extension coordinates schema changes and snapshots, delivering a more reliable, low-lag data flow from transactional Postgres to analytical Snowflake. Adoption is limited to Snowflake-hosted Postgres instances that can run the preview extension.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
A Postgres extension called snowflake_cdc pushes change batches into per-table Iceberg logs stored in object storage.
The extension has full visibility into Postgres state, allowing it to align schema changes, snapshots, and transaction boundaries automatically.
Data Mirroring provides out-of-the-box replication to Snowflake without additional infrastructure, but is only available in Snowflake’s public preview.
THE READ
What the cluster adds up to.
Traditional CDC in Postgres relies on logical decoding, which streams WAL-derived row changes to an external consumer that must infer schema evolution, handle snapshots, and recover from failures. This pull model places most of the complexity on the downstream system, leading to brittle pipelines that are costly to operate. Snowflake identified these shortcomings as a primary obstacle for reliable data mirroring.
The new approach embeds a CDC engine directly inside Postgres via the snowflake_cdc extension. Instead of exposing a raw change stream, the extension batches modifications and writes them to Iceberg tables stored in an object store, preserving transaction boundaries and coordinating DDL events. These batches are then consumed serverlessly by Snowflake, which applies them transactionally to its own tables.
For developers, the practical effect is a click-to-enable replication path: enable the extension, configure the target, and Snowflake continuously mirrors the source data with minimal lag. This eliminates the need to provision and maintain separate replication services, reducing both infrastructure spend and operational toil. The trade-off is that the feature is tied to Snowflake’s managed Postgres offering and is currently in public preview.
Because the extension runs inside the database, it can only be used on Postgres instances that allow custom extensions and that are part of Snowflake’s platform. Environments that rely on self-hosted Postgres or other cloud providers will not benefit without Snowflake’s integration. Additionally, any workloads that require non-standard replication semantics outside of the supported Iceberg format will need alternative solutions.
The design also clarifies the replication timeline by separating write, decode, capture, and apply stages, each operating on a consistent view of the database state. By aligning snapshots with ongoing change batches, the system avoids gaps or overlaps that typically cause data drift. This timeline awareness is a core reason the push model can operate as a “clockwork” process.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER