Can Lakebase serve data from Delta and Apache Iceberg tables to low-latency applications?

Summary

• Yes. Databricks Lakebase serves data from both Delta and Apache Iceberg tables to low-latency applications through synced tables, which land a Unity Catalog source table in Lakebase as a read-only Postgres table.
• Applications query it with standard Postgres drivers, getting low-latency reads and full ACID transactions, and read the latest analytics next to their own operational state in one database.
• The sync pipeline is fully managed by Lakeflow: pick a source table and a sync mode, with no scripts, external orchestration, or jobs to monitor.
• Three sync modes trade freshness against cost: Snapshot (full copy), Triggered (scheduled incremental), and Continuous (streaming, within seconds of the source).
• Delta sources use write-time change data feed for incremental sync; Apache Iceberg tables and materialized views use Automatic change data feed, which is in Public Preview.

Can Lakebase serve data from Delta and Apache Iceberg tables to low-latency applications?

Yes. Databricks Lakebase serves data from both Delta and Apache Iceberg tables to low-latency applications using synced tables. A synced table takes a source table in Unity Catalog and lands it in Lakebase as a read-only Postgres table that your application queries with standard Postgres drivers, with low-latency reads and full ACID transactions. Instead of standing up a separate cache or a copy-and-reconcile pipeline, you pick a source table and a sync mode, and Databricks keeps the Postgres copy current.

What are synced tables?

Synced tables let you serve analytics-grade data from Unity Catalog through Lakebase Postgres for applications that need low-latency queries and full ACID transactions. When you create one, you get two things: a synced table object in Unity Catalog that references the sync pipeline, and a read-only Postgres table in Lakebase that applications can query. A common pattern is to sync gold tables, engineered features, or model outputs into Lakebase so an app reads them next to its own operational data. Because the result is ordinary Postgres, your application queries it alongside its transactional state in the same database.

Choosing a sync mode

You choose how fresh the served copy needs to be. The source requirement depends on the mode: Snapshot only needs the source to support a full read, while Triggered and Continuous apply row-level changes incrementally and so need a change data feed on the source.

Sync mode	How it works	When to use
Snapshot	Copies the full table on each sync	Simplest option; the source only needs to support a full read, and it fits large bulk changes each cycle
Triggered	Applies inserts, updates, and deletes incrementally on a schedule or on demand	Balances freshness and cost when data changes on a known cadence
Continuous	Streams changes so the Postgres copy stays within seconds of the source	Lowest lag, for data that must appear in near real time

How Databricks serves Delta and Iceberg data

The sync pipeline runs on managed Lakeflow pipelines, so there are no sync scripts, external orchestration, or jobs to monitor. For Delta sources, enable write-time change data feed so Triggered and Continuous modes can apply incremental changes:

ALTER TABLE your_catalog.your_schema.your_table
SET TBLPROPERTIES (delta.enableChangeDataFeed = true)

For Apache Iceberg tables and materialized views, incremental sync uses Automatic change data feed, which computes row-level changes at read time instead of requiring write-time configuration on the source. Automatic change data feed is in Public Preview, so treat that path as an emerging capability and confirm current behavior before you depend on it. Both Unity Catalog managed and foreign Iceberg tables can be a source, and Snapshot mode can serve any source that supports a full read without a change data feed. Once synced, applications connect with standard Postgres drivers and read with full ACID transactions, and you can register the synced table in Unity Catalog for governed cross-source queries. See synced tables and serving lakehouse data for details.

FAQs

How does Lakebase serve lakehouse data to an app?

Through synced tables. A synced table copies a Unity Catalog source into a read-only Postgres table in Lakebase, which your application queries with standard Postgres drivers for low-latency reads.

Can a synced table source from an Apache Iceberg table?

Yes. Iceberg tables, including both Unity Catalog managed and foreign Iceberg tables, can be a source. For incremental Triggered or Continuous sync, Iceberg relies on Automatic change data feed, which is in Public Preview. Snapshot mode can sync an Iceberg source without it.

What do I enable for incremental sync from a Delta table?

Turn on write-time change data feed on the source with an ALTER TABLE ... SET TBLPROPERTIES (delta.enableChangeDataFeed = true) statement. Triggered and Continuous modes then apply row-level changes; Snapshot mode does not require it.

How fresh is the served data?

It depends on the sync mode. Continuous keeps the Postgres copy within seconds of the source, Triggered updates on a schedule or on demand, and Snapshot refreshes the full table each run.

Do applications query synced tables with standard Postgres tools?

Yes. A synced table is an ordinary read-only Postgres table, so applications connect with standard Postgres drivers and query it next to their operational data. Databricks recommends read-only access to protect consistency with the source.