Snowflake宣布Postgres数据镜像正式可用，可将Postgres变更实时复制到Snowflake或Iceberg表

Your app data shouldn't need a complex pipeline to become your analytics data. Starting today, it doesn't: Postgres data mirroring is now generally available.
Postgres data mirroring seamlessly replicates your Postgres tables into Snowflake for analytics and AI. You can set up a mirror in seconds, and every insert, update and delete flows directly into Snowflake. Schema changes carry over on their own, and new tables are picked up automatically.
Best of all, there's no external infrastructure to deploy or manage. It's just Postgres working smoothly with Snowflake.
Figure 1: Overview of Postgres data mirroring.
Data mirroring eliminates the pipeline tax
Ask any data team about their most painful job, and you'll hear the same answer: moving data between transactional and analytical systems. Teams struggle with babysitting CDC connectors, batch jobs that break and snapshots that drift. This problem has existed for 30 years, and we’ve become too desensitized to it being that way.
Timeliness matters in the age of AI. Having your data ready and in a location where you can take action on it in real time unlocks business value, both by removing technical debt and by giving teams the data they need without delay. Pipelines that lag and need constant babysitting don't just cost engineering time. They leave your data hours or days behind reality. A fraud model can't stop today's attack with last night's batch load. Data mirroring makes this gap disappear.
How it works: Postgres data mirroring
Data mirroring continuously replicates your Postgres data into Snowflake in seconds. Once you create a mirror, Snowflake maintains target tables that reflect the current state of their source tables, including schema changes and new tables you add to mirrored schemas.
Set it up in a few clicks in the Snowsight interface or with a single SQL command — or better yet, just ask Snowflake CoCo.
Figure 2: Setting up data mirroring.
With data mirroring, you get:
No extra infrastructure:
Mirrors run inside Snowflake, so there are no additional services or vendors to deal with.
Fresh reads:
Every mirrored table includes a $live view combining already-applied data with in-flight changes. Readers see committed source changes within seconds.
Transactional consistency:
Changes from a single source transaction appear on the target together. Foreign keys hold, and joins stay accurate.
Built-in change history:
Every table gets a seven-day change feed ($changes) showing inserts, updates and deletes. This is queryable from both Snowflake and Postgres.
High throughput at scale:
An optimized apply strategy skips full-table scans, so cost and performance stay stable as your data grows.
Plus, it’s all built on an open foundation.
Under the hood, mirroring uses
pg_lake
, Snowflake's open source Postgres extension, to capture changes via standard logical replication and write them into Apache Iceberg™ tables. There's no proprietary layer between your database and your data. You can mirror into standard Snowflake tables for simplicity or into Iceberg tables on your own storage for full portability.
Why data mirroring is different: Push, don't pull
Most replication tools wedge a separate service between your database and Snowflake. That service pulls changes over the network without knowing what's happening inside Postgres: when a schema changed, how a snapshot lines up with in-flight changes, or whether the database is down or just the network. Data mirroring flips that model.
A Postgres extension captures changes from inside the database and pushes them, in transactional batches, into open Iceberg change logs in object storage. Snowflake then applies those batches with serverless compute, also transactionally. Because the extension sees everything happening in Postgres, it coordinates snapshots, schema changes and recovery at the source, so they don’t collide downstream.
Transactions on both sides mean every mirrored table moves forward together, landing exactly on a Postgres transaction boundary. Inserts are appended rather than upserted, so the biggest, most insert-heavy tables stay fast and cost-efficient as they grow.
The results:
No new vendors
to evaluate, pay for and manage
No new infrastructure
to deploy and monitor
No upserts that slow down
as your tables grow
No lock-in on your change data,
since it lands in open Apache Iceberg tables, and mirroring is built on our open source pg_lake extension
What teams are building with data mirroring
Data mirroring is useful anywhere your analytical or AI workloads depend on fresh transactional data. Here's what teams are doing with it today:
One fewer vendor on the invoice:
A data platform team running middleware to get Postgres data into Snowflake can replace entire pipelines with a single CREATE_MIRROR call.
Ericsson
did exactly this,
consolidating four legacy databases, eliminating sync pipelines and reducing data processing time by 99%.
Dashboards that show what's happening now:
An e-commerce team mirrors their orders table to Snowflake. Every purchase, cancellation and return shows up in seconds. Their ops dashboard reflects live revenue, not yesterday's close. When a flash sale spikes, they see it immediately instead of in tomorrow's report.
AI agents that actually know what's going on:
A support team mirrors customer accounts and order history into Snowflake, where Snowflake Cortex AI agents join it with product data, shipping status and past interactions. When a customer asks "Where's my order?" the agent answers from the current state of the business.
Fraud and risk scoring on live transactions:
A financial services company mirrors payment events into Snowflake and runs scoring models against them in real time. Suspicious patterns get flagged before the money settles, not the next morning when a batch job finally runs.
Audit trails you don't have to build:
A compliance team uses the $changes feed to answer "What changed and when?" without maintaining custom history tables. Every insert, update and delete across mirrored tables is queryable for seven days.
“Before, our application data and our analytics data lived in two different places. Now it's all in Snowflake. Transactional data mirrors to Snowflake automatically, so our customers can leverage AI over it without extra work."
Alan Buxton
Chief Technology Officer, Simfoni
Get started with data mirroring in minutes
Data mirroring is available today on AWS and Microsoft Azure in every region where
Snowflake Postgres
runs. You can start using Postgres data mirroring in three steps:
Spin up Snowflake Postgres, or use an instance you already have.
Create a mirror with a few clicks in Snowsight, with a single SQL command or by asking CoCo. Choose specific tables, a full schema or a database.
Query your data in Snowflake using the target tables.
CALL SNOWFLAKE.POSTGRES.CREATE_MIRROR(
mirror_name => 'data_mirror',
postgres_instance => 'my-pg',
postgres_database => 'postgres',
target_database => 'MIRRORTOSNOWFLAKE',
postgres_tables => NULL,
postgres_schemas => ['public'],
refresh_interval => '1 minute',
warehouse => NULL
);
Then set it and forget it.
One more thing:
If you’re thinking about how you mirror data from Snowflake analytics back to Postgres, stay tuned!
Check out these resources to learn more about data mirroring and Snowflake Postgres:
Data mirroring overview
Create your first mirror
How we pushed CDC into Postgres
Watch the webinar: "Replicate Data from Postgres to Snowflake Analytics in Real Time with Data Mirroring"
Forward-looking statements
This article contains forward-looking statements, including about our future product offerings, and are not commitments to deliver any product offerings. Actual results and offerings may differ and are subject to known and unknown risk and uncertainties. See our latest 10-Q for more information.