Databricks Lakebase: Postgres next to the lakehouse

Databricks Lakebase is a managed Postgres database that lives inside your Databricks workspace. It is for the work a LakehouseLakehouseOne store for all of an organisation's data: cheap files in cloud storage, as in a data lake, with the tables, transactions and fast queries of a data warehouse on top. table does badly: an app or an agent reading and writing one row at a time, many times a second, and expecting an answer in milliseconds.

That is the whole difference from the lakehouse. A Delta table on object storage is built to scan millions of rows for a report. A Postgres table is built to find order 48213 by its index, change its status inside a transaction and commit. Lakebase gives you the second without leaving Databricks, and it moves data between the two for you.

Lakebase vs the lakehouse

You keep both. Analytics stays on Delta, and the app's live data sits in Lakebase. A synced table copies a Unity Catalog table into Postgres for the app to read, and Lakebase Change Data Feed writes every change the app makes back as a Delta table. Both are below.

How it is built, and why that matters for the bill

A classic Postgres server keeps its write-ahead log and its data files on the same machine's disk. Lakebase splits that machine in 2. Compute is a stateless Postgres process. Storage is a separate layer: safekeepers hold the write-ahead log, pageservers serve the data pages, and cloud object storage keeps everything durable.

3 features you will meet in the console come straight from that split:

• Scale to zero. Compute holds no data, so it can be shut down when idle and started again on the next query in a few hundred milliseconds.
• Branches. A new branch points at the same pages as its parent and stores only what changes afterwards, so a copy of a 500 GB database appears in seconds.
• Read replicas. Extra read-only computes read the same storage, with no copy of the data to pay for.

If you have used Neon, this is the same design, and Databricks' docs note that Lakebase is also offered on the Neon.com platform.

What Lakebase costs

You pay for compute and storage separately.

Compute is billed in Capacity Units (CU). 1 CU has 2 GB of RAM. A compute autoscales between a minimum and a maximum you set, up to 64 CU, and the gap between the 2 can be at most 16 CU. Databricks' price data for AWS lists Lakebase at $0.40 a DBU and 0.23 DBU per CU-hour on Premium in US East: $0.092 per CU-hour. Enterprise is $0.111. Other regions cost more, from $0.44 a DBU in Ireland to $0.83 in Brazil, where a CU-hour is $0.191.

Storage is billed per GB-month, in 3 kinds. Databricks prices point-in-time restore history at $0.20 and snapshots at $0.09, and says these are about 42% and 74% cheaper than regular branch storage. By our sum, that puts branch storage near $0.35 per GB-month; check system.billing.list_prices for your own rate.

2 rules move the compute line most:

1. Scale to zero works only when the maximum is 32 CU or less, and never with high availability. The default timeout is 24 hours; it can be anything from 60 seconds to 7 days.
2. Always-On pricing applies when you turn scale to zero off. The minimum of your range is billed 25% lower once the compute has run 24 hours without stopping. Databricks stacks a further 50% promotional discount on that until 31 January 2027.

Those 2 rules pull in opposite directions, and the default sits in the worst place for one common app.

The default timeout and an office-hours app

Take an internal tool used on weekdays from 8:00 to 18:00, nobody at night or at weekends. It needs about 2 to 5 CU while people work. Set it to autoscale from 2 to 8 CU and try the 4 timeouts below, or use the widget with your own traffic.

Try itA week of a Lakebase compute

Traffic

·Customer app, busy every evening·Internal tool, office hours·Development branch, a few hours a day

Minimum CU

2

4 GB of RAM

Maximum CU

8

16 GB of RAM

Never5 min30 min24 h

Compute billedWhat the traffic asks forAsleep, nothing billed

With the widget's office pattern, at $0.092 per CU-hour, a month comes to:

The 24-hour default never fires on a weekday: the compute goes quiet at 18:00 and the next query arrives at 8:00, 14 hours later. It sleeps only from Saturday evening to Monday morning. You lose the Always-On discount and gain almost nothing back, so it costs slightly more than turning scale to zero off. A 30-minute timeout sleeps every night and cuts the bill nearly in half.

Going from 30 minutes to 5 saves only another dollar or so, and each wake clears the session: temporary tables, prepared statements, session settings and the cache go. The first query after a wake also waits a few hundred milliseconds, so your app should retry a connection that fails while the compute starts.

The range matters as much as the timeout. A new project starts at 8 to 16 CU with the 24-hour timeout. The same office tool at those settings uses about 4,519 CU-hours, roughly $416 a month, because the 8 CU minimum is billed all week long. Set the minimum from what the app needs when it is quiet, not from its peak. Databricks' cost guide puts the useful cache at up to 75% of RAM, so size the minimum so the rows the app reads most fit in it.

A customer-facing app that is busy every evening is the other case. Its traffic never stops long enough for any timeout, so turn scale to zero off and take the 25%.

Getting lakehouse data in: synced tables

A synced table takes a Unity Catalog table and keeps a read-only copy of it in Postgres, through a managed Lakeflow pipeline. The app reads the copy with an index; it never writes to it.

There are 3 modes:

• Snapshot copies the whole table each time. It needs nothing from the source, and Databricks says it can be up to 10 times more efficient than Triggered when more than 10% of the rows change between runs. A nightly refresh of a scores table is the usual fit.
• Triggered applies only the rows that changed since the last run. Run it from a job that starts when the source table is updated. Databricks warns it gets expensive below 5-minute intervals.
• Continuous streams changes, at intervals of 15 seconds or more. It has the least lag and the highest cost, since the pipeline runs even when nothing changes.

Triggered and Continuous read the source's change data feed, so turn it on first:

ALTER TABLE main.sales.customer_scores
  SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

3 things trip people up. The sync pipeline runs on serverless compute, billed apart from Lakebase. Each sync can open up to 16 connections to the database, and a small compute has few to spare. And rows whose primary key is null are left out of the copy without an error, so check the key before you sync.

Getting app data out: Lakebase Change Data Feed

The other direction is in Public Preview. Lakebase Change Data Feed reads the Postgres write-ahead log and writes every insert, update and delete as a new row in a Delta table called lb_<table>_history, about every 15 seconds. No Debezium, no Kafka, no Change Data CaptureChange Data CaptureCopying only the rows that were added, changed or deleted in a source database, read from its change log, instead of copying the whole table again. job of your own.

Each table needs its old row values in the log, which Postgres does not record by default:

ALTER TABLE orders REPLICA IDENTITY FULL;

Each history row carries _pg_change_type (insert, delete, update_preimage or update_postimage), _pg_lsn, _pg_xid, _timestamp and _sort_by, a key that orders every change. To rebuild the current state of each order in the lakehouse, keep the newest change per key and drop the deleted ones:

SELECT * EXCEPT (rn)
FROM (
  SELECT *,
         ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY _sort_by DESC) AS rn
  FROM main.app.lb_orders_history
  WHERE _pg_change_type <> 'update_preimage'
)
WHERE rn = 1 AND _pg_change_type <> 'delete';

2 limits to plan for: a schema change on the Postgres table makes the feed re-read and rewrite the whole table, and a row filter or column mask on the history table stops the feed writing to it. Put masks on a view over it.

Branches without the surprise storage bill

A branch is a copy of the database for a developer, a test run or a pull request, made in seconds whatever the size. Changes on a child never reach its parent, and you reset a child from its parent to get fresh data. Moving changes the other way is a migration, as with any Postgres database.

The bill depends on one setting. An expiring branch is billed only for the data that changes on it: change 1 GB on a branch of a 100 GB database and you pay for about 1 GB. A branch set to never expire is billed for its full size, like a separate database. Give every development branch an expiry, and use a 30-minute scale-to-zero timeout on its compute.

Point-in-time restore works the same way. To get back a table dropped at 10:23, you create a new branch at 10:22 and copy the rows out. The restore window runs from 2 to 30 days; a longer window keeps more history, billed at the PITR rate.

Lakebase for agents and features

Agents need somewhere to keep a conversation between turns and what they learned across sessions. Databricks' agent templates store both in Lakebase: short-term Agent MemoryAgent MemoryThe ways an agent keeps what it needs beyond a single context window, such as summaries, notes in files, and saved facts it reads back later. The model itself remembers nothing. as checkpoints per thread, through LangGraph checkpointers or the OpenAI Agents SDK, and long-term memory as rows the agent reads back later. It is plain Postgres, so the same database can hold the app's own tables.

Online feature stores for Model Serving run on Lakebase too, and the lakebase_vector and lakebase_text extensions add vector and keyword search, the job pgvectorpgvectorA PostgreSQL extension that adds vector similarity search. does elsewhere. Scale to zero suits an agent used in office hours; an agent that must answer at once at 3:00 needs the compute kept on.

When Lakebase is the wrong tool

• Reports and scans. A query that reads a year of orders belongs on a SQL warehouse over Delta. Run it on Lakebase and you pay to hold all that data in Postgres and still wait.
• A database that must never pause. High availability turns off scale to zero, and so does a maximum above 32 CU. That is the right choice for production, but price it as always on.
• Writes to synced data. A synced table is read-only in Postgres. If the app changes a value, it belongs in a table the app owns, and Change Data Feed carries it back.

Before you build, set 3 numbers yourself rather than keeping the defaults: the minimum CU from your quiet hours, the scale-to-zero timeout from the longest gap in your traffic, and an expiry on every branch. To compare Lakebase with the rest of your Databricks bill, the Databricks cost calculator prices the clusters and SQL warehouses around it.