Snowflake makes Postgres-to-Snowflake data mirroring generally available
Snowflake makes PostgreSQL data mirroring generally available for its managed Postgres service, supporting continuous replication, automatic schema updates and low-lag analytical views.
The release continuously replicates Snowflake Postgres tables into the analytics platform without a separate CDC service. Support remains limited by cloud provider, account and region.
Snowflake made Postgres-to-Snowflake data mirroring generally available on 15 October 2026, allowing tables from its Snowflake Postgres service to be continuously replicated into Snowflake for analytics and AI workloads. The feature captures inserts, updates, deletes and schema changes without a separately managed change-data-capture connector, according to the company.
In its official announcement, Snowflake said mirroring removes the need to operate a separate replication pipeline between its managed PostgreSQL service and analytical databases. The release extends the Snowflake Postgres offering rather than enabling automatic mirroring from every externally hosted PostgreSQL database.
Changes replicate without a separate CDC pipeline
Mirroring uses PostgreSQL’s logical replication capabilities to capture data changes and stores them in Apache Iceberg change logs. Snowflake then applies those changes to destination tables through managed serverless tasks.
The process handles initial data snapshots, subsequent row changes and supported schema modifications, including added or removed columns. Snowflake says changes from a source transaction are applied together, maintaining transactional consistency across mirrored tables.
This replaces infrastructure commonly associated with connector-based CDC, although the replication still consumes compute and storage resources.
Live views expose changes before table refreshes
Snowflake’s data mirroring documentation describes two ways to examine replicated information.
Mirrored tables receive changes according to a configurable refresh interval. Companion $live views combine those tables with pending changes, offering lower-lag access without requiring every update to be merged immediately.
Snowflake describes approximately 30-second lag for these views under its documented architecture, rather than guaranteeing that all workloads will always achieve that latency.
A separate $changes feed makes seven days of inserts, updates and deletes queryable. This provides access to recent changes in addition to the latest replicated table state.
Availability and source requirements remain limited
Snowflake’s 15 October release notes confirm general availability on AWS and Microsoft Azure. Mirroring currently requires the source and destination to remain within the same Snowflake account, region and cloud provider.
The source must be a supported Snowflake Postgres instance. Existing instances may require a software refresh, while tables need compatible structures. Snowflake’s setup instructions also specify that primary keys are required when mirrored source tables must support updates and deletes.
These requirements limit deployment despite the general-availability designation. Snowflake has not established that its mirroring service supports arbitrary external PostgreSQL installations or unrestricted cross-cloud replication.