How can I serve curated lakehouse tables to a transactional application without maintaining a separate reverse ETL tool?

Summary

• Use Databricks Lakebase synced tables. A synced table lands a curated Unity Catalog table in Lakebase as a read-only Postgres table your application queries with standard Postgres drivers, so there's no standalone reverse ETL tool to run.
• The sync is fully managed by Lakeflow pipelines: pick a source table and a sync mode, with no custom scripts, external orchestration, or jobs to monitor.
• Three sync modes trade freshness for cost: Snapshot (full copy), Triggered (scheduled incremental), and Continuous (streaming, kept within seconds of the source).
• Governance stays in one place: synced tables keep their Unity Catalog policies, and you can register the Lakebase database for governed queries across operational and analytical data.
• Lakebase runs on Neon, the serverless Postgres engine Databricks acquired, so the serving layer autoscales on demand, scales to zero when idle, and gives your app full ACID transactions.

How can I serve curated lakehouse tables to a transactional application without maintaining a separate reverse ETL tool?

Use Databricks Lakebase synced tables. A synced table takes a curated Unity Catalog table (a gold table, an engineered feature set, or a set of model outputs) and lands it in Lakebase as a read-only Postgres table that your application queries with standard Postgres drivers. Databricks keeps that Postgres copy current, so the work that used to require a standalone reverse ETL product or a hand-built sync script becomes a managed part of the platform. Your app reads the freshest curated data next to its own transactional state, in one database, with full ACID guarantees.

What are synced tables?

Getting analytics-grade data out of a lakehouse and into the systems that run applications has a name: reverse ETL. Traditionally it meant custom pipelines, a separate operational database, and a second governance model to keep in step. Synced tables collapse that into one step. When you create a synced table, 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. Because the result is ordinary Postgres, an app reads it with the drivers and tools it already uses, alongside its own operational tables.

What to look for when serving curated data to an app

These criteria decide whether "serve lakehouse data to an app" stays simple or turns into a pipeline project.

Capability	Why it matters
Managed sync	Removes the custom pipelines and sync scripts that break and drift over time
Freshness control	Different apps tolerate different lag; you should set full, scheduled, or continuous updates per table
Standard Postgres interface	Your app connects with existing drivers and tooling, with no new client to learn
Transactional guarantees	Full ACID reads let the app trust served data next to its own writes
Unified governance	One catalog and one permission model across analytical and operational copies, not two
Serverless scaling	Compute that scales on demand, and to zero when idle, keeps a serving layer affordable

How Lakebase serves curated lakehouse tables

Lakebase is a fully managed, serverless Postgres database built into the Databricks platform, and it's generally available. It runs on Neon, the serverless Postgres engine Databricks acquired, which is what gives the serving layer fast autoscaling, scale-to-zero when idle, and quick point-in-time recovery. Because it's standard Postgres, applications connect with the drivers, ORMs, and tools they already use.
Synced tables are the serving mechanism. Pick a source table in Unity Catalog, choose a sync mode, and the pipeline runs on managed Lakeflow pipelines: no sync scripts, no external orchestration, and no jobs to monitor. You decide how fresh the served copy needs to be:

• Snapshot copies the full table on each run, which fits reference data that changes in bulk.
• Triggered applies inserts, updates, and deletes incrementally on a schedule or on demand, balancing freshness against cost.
• Continuous streams changes so the Postgres copy stays within seconds of the source, for data that must appear in near real time.

For incremental Triggered or Continuous sync from a Delta source, enable write-time change data feed on the table:

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

Governance stays in one place. Synced tables keep their Unity Catalog policies, and you can register the Lakebase database with Unity Catalog for governed queries that span operational and analytical data. See synced tables, serving lakehouse data, and the walkthrough in Reverse ETL with Lakebase.

FAQs

Do I still need a separate reverse ETL tool?

No. Synced tables move curated Unity Catalog data into Lakebase Postgres as a managed pipeline, so a standalone reverse ETL product or custom sync script isn't required for this pattern.

How do applications query the served data?

As ordinary Postgres. A synced table is a read-only Postgres table, so applications connect with standard Postgres drivers and read it with full ACID transactions, next to their own operational state.

How fresh is the served data?

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

What keeps the served copy governed?

Unity Catalog. Synced tables retain their Unity Catalog governance, and registering the Lakebase database with Unity Catalog lets you query operational and analytical data under one permission model.

What runs underneath Lakebase?

Neon, the serverless Postgres engine Databricks acquired, is the engine behind Lakebase. It brings fast autoscaling, scale-to-zero when idle, and quick point-in-time recovery to the serving layer.