Lakebase, the Postgres inside Databricks

What it is

Lakebase is a managed PostgreSQL database that lives inside Databricks. You get a real Postgres — the same wire protocol, the same SQL, the same drivers and tools — without running a server, patching it, sizing its disks or arranging its backups. It sits next to the lakehouse rather than inside it: Delta tables stay the place for analytics, Lakebase is the place for rows an application reads and writes one at a time.

In the workspace it is not an entry in the left sidebar. It is its own app, Lakebase Postgres, opened from the app switcher at the top right. The one thing you start from the sidebar is a synced table, which is created from Catalog (see Synced tables, from Unity Catalog into Postgres).

Lakebase has been generally available since January 2026, and its management APIs — REST, CLI and SDKs — since August 2026. It supports Postgres 16, 17 and 18, with 17 the default.

Why it exists

A lakehouse is built for scanning: columnar files, large reads, many rows at once. An application that updates an order, checks a session or records a click needs the opposite — single-row reads and writes in milliseconds, transactions, indexes, many small concurrent connections. Teams used to run a separate operational database for that, outside the platform, and then build pipelines to move data between the two in both directions, each with its own credentials and its own idea of who may see what.

Lakebase keeps that database inside Databricks. Databricks describes the arrangement as LTAP, lake transactional and analytical processing: the storage layer turns the Postgres rows into columnar files as they land in object storage, so the transactional and the analytical side can work from one logical copy of the data instead of a pipeline copying it across. The practical uses the documentation lists are:

• the database behind a low-latency application or a Databricks App;
• serving Unity Catalog tables to applications over Postgres, through Synced tables, from Unity Catalog into Postgres;
• recording Postgres changes as Delta tables, through the Lakebase change data feed, from Postgres into Delta;
• an Online Feature Store or the state store of an agent.

How it works

Compute and storage are separate. A Postgres compute is stateless and can start, stop and resize without touching the data; the data lives in a durable storage layer backed by cloud object storage. That separation is what makes the rest possible:

• Branches — a copy of a whole database, created in seconds whatever its size, because it shares storage with its parent until it diverges. See Projects, branches and point-in-time restore.
• Autoscaling and scale-to-zero — a compute grows and shrinks with load and suspends when idle. See Computes, autoscaling, scale-to-zero and high availability.
• Point-in-time restore — any moment inside the retention window can become a new branch.

The top-level object is a project. A project holds branches; each branch holds its own computes, Postgres roles and databases. A new project starts with a production branch and a databricks_postgres database.

Two layers of permissions

Two different systems decide what someone may do, and they do not replace each other:

Unity Catalog governs the analytical access to Lakebase data — a registered catalog queried from a SQL warehouse (Registering a Lakebase database in Unity Catalog). An application connecting to Postgres directly is governed by Postgres grants. See Connecting to Lakebase, roles and permissions.

Provisioned and Autoscaling

The first version of Lakebase, now called Provisioned, had fixed-size instances you resized by hand, sized in capacity units of 16 GB. From March 2026 every new instance was created as an Autoscaling project instead, and the existing instances were upgraded, a migration that finished in July 2026. What is left is simply called Lakebase. The older interfaces still answer for upgraded instances — the databricks database CLI group, database_instances in bundles — but new work uses the databricks postgres group and the w.postgres SDK module.

Where it runs

On AWS, Lakebase is available in twelve regions across North America, South America, Europe and Asia Pacific, and a project is always created in the region of its workspace. Compute is measured in capacity units (CU), each about 2 GB of memory with matching CPU and local SSD. Project tags reach system.billing.usage, so Lakebase spend can be attributed like any other workload (see Cost attribution and budgets).

Example

Creating a project from the CLI, choosing the Postgres version:

databricks postgres create-project my-app \
  --json '{"spec": {"display_name": "My Application", "pg_version": 17}}'

The command waits for the project to be ready and returns it, with its production branch and primary compute already in place.

Common mistakes

• Treating it as a lakehouse table. Lakebase is Postgres: tables need primary keys and indexes, and a query that scans millions of rows belongs on a SQL warehouse against Delta, not on a transactional compute.
• Expecting Unity Catalog grants to protect the database. They cover warehouse queries against a registered catalog. A client with a Postgres role reaches whatever Postgres grants allow.
• Reading old material literally. “Database instance”, CU_1 to CU_8 and the Compute tab entry point describe Provisioned. The concepts carry over; the names and sizes do not.
• Looking for it in the sidebar. It is an app of its own, in the app switcher.