Snowflake's Postgres Mirroring Is GA: How It Stacks Up Against Databricks Lakebase

On October 15 Snowflake made data mirroring for Snowflake Postgres generally available.¹ Inserts, updates, deletes and schema changes on a Snowflake-managed Postgres instance now flow into Snowflake without a replication service of your own.

Databricks Lakebase, also a managed Postgres, streams changes into Unity Catalog Delta tables and can sync lakehouse tables back.⁵⁷ Both vendors want to remove the hand-built pipe between application database and analytics. First what Snowflake shipped, then the two side by side.

Snowflake lets Postgres push its own changes out

Mirroring runs on pg_lake, Snowflake’s open-source Postgres extension. It captures changes with standard logical replication, pushes them in transactional batches to Apache Iceberg change logs, and Snowflake applies them to the target tables with serverless compute.¹ The analytics side never scans the application database.

One CREATE_MIRROR call mirrors chosen tables, a schema or a database, and new tables in a mirrored schema join automatically. Targets are standard Snowflake tables or Iceberg tables.¹² Each mirrored table also gets $changes, a seven-day change feed, and a $live view that adds in-flight changes to merged data.¹³

It runs on AWS and Azure, never across accounts, regions or clouds.² There is no published price. Snowflake says Ericsson consolidated four legacy databases with it and cut data processing time by 99%.¹

Side by side, Snowflake is more consistent and Databricks goes both ways

	Snowflake Postgres mirroring	Databricks Lakebase
Maturity	generally available (GA) on AWS and Azure	Postgres to lakehouse: still in Public Preview
How it syncs	an extension in Postgres pushes changes out; Snowflake merges them into tables	an extension in Postgres writes changes to a log table in the lakehouse
How fresh	live view in about 30 s; target tables merge every 10 min by default①	a batch about every 15 s
Whole transactions?	yes in target tables, all updated together; the live view may show half②	not guaranteed; each row has a transaction ID to regroup yourself③
Change history	last 7 days only④	kept as it grows, but only as a log; current state is yours to compute
Schema changes	new tables join automatically; column types cannot be changed in place	adding, dropping or retyping a column re-copies that table in full
Back to Postgres?	not yet; Snowflake only says it is coming	yes: lakehouse tables sync back, read-only, as often as every 15 s⑤
Prerequisites	not on the smallest instance tier; 10 mirrors per instance by default	Postgres 16–18; tables must log full rows; no partitioned tables

1. ①The live view ($live) adds changes not yet merged to the merged data; it is what the blog means by "within seconds". The merge interval (refresh_interval) sets how often target tables catch up: 10 minutes by default, 30 seconds to a day.
2. ②Fresh or whole, pick one: point reconciliation and reports at the target tables and accept the merge lag; a shorter interval costs more merge compute.
3. ③The transaction ID is the _pg_xid column. The Databricks docs promise no cross-table consistency, so you use it to line up one transaction across tables.
4. ④Those seven days live in the $changes table. If Postgres falls too far behind and its replication position is dropped, the mirror re-copies every table and the seven days of history are lost.
5. ⑤These "synced tables" are read-only in Postgres: app writes are overwritten on the next refresh. They sync about 150 rows per second per compute unit.

Three of these differences are easy to miss.

“Within seconds” means the $live view, which can show half a transaction

The blog promises committed changes within seconds.¹ The docs describe three layers: $changes follows the source, $live refreshes from it every 30 seconds, and target tables merge every refresh_interval, 10 minutes by default and anywhere from 30 seconds to a day.²³

The docs also say $live is not transactional: it can show some rows of a transaction before others, and for consistency you should query the target tables.³ So with the defaults you pick fresh or whole. $live may show the debit of a transfer without the credit; the target tables show both, up to about 10 minutes late. A shorter interval costs more, because every $live query scans all unmerged $changes rows.³ I would send reconciliation, audit and external reports to the target tables, and dashboards and alerts to $live.

Databricks hands you a change log and leaves current state to you

Lakebase Change Data Feed, in Public Preview, decodes the WAL with the wal2delta extension and writes a batch about every 15 seconds into one lb_<table>_history Delta table per source table.⁵ It is configured per schema and picks up new tables automatically.⁶

Each row carries the change type, _pg_lsn, _pg_xid and a timestamp, and an update becomes a before row and an after row.⁵ Auditors like that shape. Current state, though, you build yourself with a materialized view, a Lakeflow pipeline or a streaming MERGE.⁵ Cross-table consistency is not documented; _pg_xid should let you regroup changes by transaction, but that work is yours.

Databricks syncs results back today; Snowflake says “stay tuned”

Databricks synced tables copy Delta tables, Iceberg tables and views from Unity Catalog into read-only Lakebase Postgres tables, in Snapshot, Triggered or Continuous mode. Continuous runs as often as every 15 seconds; Triggered gets expensive below five-minute intervals.⁷ That suits sending recommendation scores or risk flags back to an application.

Snowflake’s blog only says reverse mirroring is coming, with no date.¹ Until then, results go back to Postgres through a pipeline of your own.

Choose by the direction your data moves

• Application data for analytics, already on Snowflake: mirroring is GA and moves tables forward together by transaction. Pick target tables or $live per use case, and treat refresh_interval as a cost knob.
• Results back to the application, or a full before-and-after change log: Databricks covers both directions, but check the prerequisites in the last row of figure 1 before relying on the preview leg.
• Long-lived history for audit: $changes keeps seven days, and a re-snapshot after slot invalidation drops the incremental history,³⁴ so copy it out on a schedule. Lakebase history tables are append-only with no documented retention limit, but consistency is on you.

Snowflake finished consistency first; Databricks finished both directions first. Pick by the way your data travels most.