Snowflake makes Postgres data mirroring generally available

Snowflake has made Postgres data mirroring generally available, giving Snowflake Postgres users a managed route to continuously copy selected tables and schemas into Snowflake databases.

For this path, Snowflake says the feature removes the need to operate a separate replication service. It can send data to regular Snowflake tables or Snowflake-managed Iceberg tables, while a live-view option exposes newer changes before the configured materialization cycle finishes. Snowflake’s release note dates general availability to October 15; the company published its engineering explanation on October 20.

A mirror can cover individual tables, entire schemas or both. Selecting a schema also brings in tables added to that schema later, according to Snowflake’s data-mirroring documentation. The service is available on AWS and Azure in regions where Snowflake Postgres is offered, but a mirror cannot span accounts, regions or cloud providers.

On the source, a Postgres publication and logical replication slot feed write-ahead-log changes to a Snowflake CDC worker. About every 15 seconds, that worker uses pg_lake to write a separate Iceberg $changes log for each table and an Iceberg metalog that tracks the batch. On the destination, a scheduled serverless task reads the metalog and applies accumulated changes at a configurable interval.

The metalog is also how Snowflake says it preserves transaction boundaries across tables during the materialization step. The company commits the referenced change-log batch and metalog together, then applies the batch to target tables in one Snowflake transaction. If an apply operation fails, it rolls back and restarts from the same metalog position rather than partially advancing the materialized tables.

Snowflake describes recovery as managed as well. If retained write-ahead-log data grows past the configured limit and Postgres invalidates the replication slot, Snowflake says the service automatically begins re-snapshotting all mirrored tables after 10 minutes. Snowflake says existing target data remains queryable during that process, but the incremental $changes history is rebuilt from a new baseline. Snowflake’s troubleshooting guide also says some schema changes trigger reloads, while column-type changes and virtual generated columns are unsupported.

For fresher reads, each mirrored table includes a $live view that combines the materialized target with rows not yet applied from its Iceberg change log. Snowflake says automatic refresh typically makes those pending changes visible in roughly 30 seconds, independently of the target table’s apply interval. That path has a consistency tradeoff: the query documentation warns that live views are not transactional and can expose only part of a source transaction. Workloads that need cross-table transactional consistency must query the materialized targets instead.

Live views have recovery caveats, too. Snowflake says they can freeze at the last successful apply, briefly show fewer rows or disappear temporarily during a re-snapshot or schema-changing reload. The company documents the $changes feed as a rolling seven-day record, but says adding, dropping or renaming a column redirects it to a new empty change table and removes the earlier history from that feed.

On cost, Snowflake points mainly to serverless compute for applying changes and to storage. The company says longer refresh intervals can reduce apply cost by batching more changes, while live views move some work into queries in exchange for fresher reads. The source-side push process also shares CPU and memory with application traffic, so Snowflake’s performance guidance recommends capacity planning and workload benchmarks.

Snowflake claims larger instances can snapshot more than 1 million rows per second and sustain well over 100,000 row changes per second. Those figures have not been independently benchmarked in the supplied research, and the cited materials do not provide a generally applicable service-level guarantee for replication lag, recovery time or availability.