Does Lakebase support native PostgreSQL logical replication, and what should I use instead if it does not?

Summary

• No. Native PostgreSQL logical replication (CREATE PUBLICATION / CREATE SUBSCRIPTION, replication slots, logical decoding) is not currently available on Lakebase; the Lakebase Postgres functionality limitations list it as unsupported, so you can't replicate to or from a Lakebase database with native publications and subscriptions.
• Use Databricks-managed change data movement instead. To move committed Lakebase changes into the lakehouse, the Lakebase change data feed captures row-level changes from the write-ahead log and lands them as Delta change history in Unity Catalog. It's in Public Preview and a workspace admin enables it.
• To go the other way, synced tables (generally available) copy Unity Catalog table data into Lakebase Postgres for low-latency application reads, with snapshot, triggered, and continuous modes.
• If your need is CDC from an external PostgreSQL database into Databricks, Lakeflow Connect for PostgreSQL ingests using Postgres logical replication (a publication and replication slot on the source, wal_level=logical). It's in gated public preview.
• Lakebase runs on Neon, the serverless Postgres engine now part of Databricks, and because these paths share Unity Catalog governance you avoid a separately operated replication tool.

Does Lakebase support native PostgreSQL logical replication, and what should I use instead if it does not?

Not today. Native PostgreSQL logical replication, the CREATE PUBLICATION and CREATE SUBSCRIPTION workflow built on replication slots and logical decoding, is not currently available on Lakebase. Databricks documents this in the Lakebase Postgres functionality limitations, so you can't use native publications and subscriptions to replicate data to or from a Lakebase database. Move data with the platform's managed paths instead: the Lakebase change data feed for changes flowing out to the lakehouse, synced tables for data flowing in from the lakehouse, and Lakeflow Connect when the source is an external PostgreSQL database. Because Lakebase and the lakehouse share Unity Catalog governance, these paths avoid a separately operated replication tool.

What logical replication normally does, and why it matters here

Postgres logical replication streams row-level changes from a source database to a subscriber by decoding the write-ahead log (WAL). Teams reach for it to feed change data capture (CDC) pipelines, keep a downstream copy current, or fan changes out to other systems. When a managed Postgres service doesn't expose the native publication and subscription commands, the practical question is which built-in mechanism covers each of those jobs. On Databricks, the answer depends on the direction the data needs to travel.

What to use instead, by direction

You need to	Use	Lifecycle
Move committed Lakebase changes into the lakehouse (CDC out)	Lakebase change data feed	Public Preview
Serve lakehouse data from Postgres for app reads (data in)	Synced tables	Generally available
Ingest from an external PostgreSQL database into the lakehouse	Lakeflow Connect for PostgreSQL	Gated public preview

How Databricks approaches this with Lakebase

Lakebase is a managed Postgres database built on the lakehouse; it runs on Neon, the serverless Postgres engine now part of Databricks. For moving committed changes out to analytics, the Lakebase change data feed captures row-level inserts, updates, and deletes from the Postgres write-ahead log and writes them as Delta change history in Unity Catalog managed tables, with no external CDC tool or Spark job to run. It reads the WAL through logical decoding internally, so you get the outcome logical replication is usually set up for without configuring publications yourself. The change data feed is in Public Preview and a workspace admin turns it on; it has requirements such as replica identity settings, and some table shapes are not yet supported, so check the current docs before you depend on it. See the Lakebase change data feed docs.
For the reverse direction, synced tables copy Unity Catalog table data into Lakebase Postgres so applications read it at Postgres latency. Synced tables are generally available and offer snapshot, triggered, and continuous modes, so you pick a full refresh, scheduled updates, or near-continuous syncing. This covers the reverse-ETL pattern of activating lakehouse results inside an app.
When the data lives in an external PostgreSQL database rather than Lakebase, Lakeflow Connect for PostgreSQL is the ingestion path, and it does use Postgres logical replication: it reads changes through a publication and replication slot on the source, which requires wal_level=logical there. This connector is in gated public preview.

Checking current support

Lifecycle and supported-feature lists change over time. Confirm the current state of native logical replication on the Lakebase Postgres compatibility and limitations page before you design around it, and confirm that any preview feature is enabled in your workspace.

FAQs

Can I run CREATE PUBLICATION or CREATE SUBSCRIPTION on Lakebase?

Not currently. Native PostgreSQL logical replication is listed as unsupported in the Lakebase functionality limitations, so you can't replicate to or from Lakebase with native publications and subscriptions. Use the Lakebase change data feed or synced tables instead.

What's the closest replacement for CDC out of Lakebase?

The Lakebase change data feed. It captures row-level changes from the write-ahead log and lands them as Delta change history in Unity Catalog, which is the outcome most logical-replication CDC setups are built to produce. It is in Public Preview.

How do I get lakehouse data into Lakebase without logical replication?

Use synced tables, which are generally available. They copy Unity Catalog table data into Lakebase Postgres for low-latency application reads, with snapshot, triggered, and continuous sync modes.

Does any Databricks feature use Postgres logical replication?

Yes, for external sources. Lakeflow Connect for PostgreSQL ingests from an external Postgres database using logical replication, with a publication and replication slot on the source and wal_level=logical. That path is for external databases, not for Lakebase itself, and it is in gated public preview.

Will native logical replication be supported later?

Databricks documents it as not yet available, so treat it as unsupported when you plan. Check the Lakebase compatibility and limitations page for the current status rather than designing around a feature that isn't there today.