Databricks Lakebase Core Concepts and Autoscaling Pricing

Databricks Lakebase is a managed Postgres database integrated directly into Databricks, built for OLTP and low-latency workloads. Its Autoscaling flavor bills on two independent meters (compute in DBUs, storage in DSUs), with a cost model that sits somewhere between instance-based and serverless per-request. Below: the core concepts, what teams run on Lakebase, and the billing gotchas we’ve hit operating it.

Lakebase Core Concepts

A Lakebase deployment is organized around five primitives: projects, separated storage and compute, branches, read replicas, and the Data API.

• Projects are your database instances in the Autoscaling flavor. Lakebase comes in two flavors: Autoscaling, the actively developed one, gives you fully managed Postgres with scale-to-zero, branching, and instant restore; Provisioned, the original offering with manually scaled compute, is being phased out — since March 2026 new databases are created as Autoscaling.
• Separation of storage and compute. Data lives in a zone-redundant distributed storage layer that persists independently of compute state.
• Branches are copy-on-write clones of your database — useful for schema tests, CI, or recovery.
• Read replicas are independent read-only computes over the same storage layer, mainly used to offload read and analytical queries from the primary.
• Data API: a built-in PostgREST-compatible REST API for lightweight services and edge integrations.

What Lakebase Is Used For

Lakebase’s core applications fall into three groups: application backends, low-latency serving, and AI/ML feature lookups.

• Backend for Databricks Apps. A traditional backend database for Databricks Apps, with data locality and minimal setup.
• Low-latency serving layer. Push gold tables into Lakebase via synced tables to serve operational reads at low latency — useful for interactive dashboards.
• Feature store for AI/ML. Real-time inference lookups, or persisting agent state (conversation and workflow context) across requests.

How Lakebase Autoscaling Pricing Works

Autoscaling billing splits into two independent meters: compute, charged in DBUs based on active CU consumption, and storage, charged in DSUs per GB-month against your data footprint. Databricks publishes the rates on the Lakebase pricing page.

Meter	Billed in	What drives it
Compute	DBUs	Active CU consumption
Storage	DSUs, per GB-month	Data footprint

Each CU gives the database roughly 2 GB of RAM, along with associated CPU and local SSD. If the DBU side of that equation is unfamiliar, we’ve covered how DBUs are priced separately.

A recent addition to the model: Always-On pricing discounts baseline compute by 25% once a database has been running continuously for 24 hours, aimed at exactly the workloads that never scale to zero. The promotional rate runs through January 31, 2027.

The Three Cost Levers

You control Lakebase cost with three levers: the min/max CU autoscaling range, scale-to-zero, and copy-on-write branching.

• The autoscaling range. Min and max CU bound what the database can consume, and with it what the compute meter can bill.
• Scale-to-zero suspends compute entirely after a configurable idle period, dropping compute cost to zero while the database sleeps. For a dev environment or an internal dashboard used only during business hours, that’s most of the week: roughly 50 active hours out of 168 means the compute meter runs nothing for the remaining 70% of the time.
• Branching. Branches are copy-on-write, so a schema test or a CI clone doesn’t duplicate your storage footprint the way a full copy would. One caveat: snapshot storage has been a billable category since June 1, 2026, so restore points and branch history now show up on the storage meter.

Four Lakebase Billing Gotchas

The following four we’ve hit ourselves running Lakebase.

Minimum CU Is the Silent Budget Killer

Your minimum CU is what you pay continuously during active hours, whether queries are running or not. Setting the minimum too high “just in case” is the single most common source of unnecessary Lakebase spend.

Sync Pipelines Run on Their Own Meter

Syncing Delta tables into Lakebase for low-latency serving doesn’t ride on your query compute. Synced tables run on a managed serverless compute layer billed independently of it — and continuous sync mode never stops running.

Read Replicas Are Not Free Just Because They Share Storage

Read replicas share the same storage layer as the primary, so there’s no DSU duplication. Each replica still has its own compute endpoint, billed in DBUs.

High Availability Removes Your Biggest Cost Lever

Scale-to-zero is not available for high-availability configurations: HA computes must remain continuously active. Enable HA and you’re planning around a database that never suspends — the Always-On discount above softens the baseline, but the meter doesn’t stop.

Watching Lakebase Costs in Practice

The billing surface here is wider than “a Postgres instance” suggests: primary compute, replica endpoints, sync pipelines, and storage each meter separately, and every branch adds its changed data to the footprint. Catching a too-high minimum CU or an always-on sync pipeline in real time is hard to do by hand. That’s why we’ve added Lakebase support to LakeSentry: it monitors branch sprawl, replica costs, and unused endpoints across your Lakebase projects, alongside the rest of your Databricks spend. For the wider picture of how Databricks charges for everything else, see our Databricks pricing breakdown.

FAQ

1. What is Databricks Lakebase?

A managed Postgres database integrated directly into Databricks, built for OLTP and low-latency workloads. It separates compute from zone-redundant storage and adds copy-on-write branches, read replicas, and a PostgREST-compatible Data API.

2. How is Lakebase Autoscaling billed?

On two independent meters: compute in DBUs, driven by active CU consumption, and storage in DSUs per GB-month, driven by your data footprint. Each CU corresponds to roughly 2 GB of RAM plus associated CPU and local SSD.

3. Does scale-to-zero work with high availability?

No. Scale-to-zero is not available for HA configurations — HA computes must stay continuously active, so an HA database bills compute around the clock.

4. Do read replicas add storage cost?

No. Replicas share the primary’s storage layer, so there is no DSU duplication. Each replica does bill its own compute endpoint in DBUs.