Databricks adds branch-based restores to Lakebase Postgres

Databricks introduced branch-based restores for Lakebase Postgres. A point-in-time recovery request now creates a new database branch at the selected historical moment. The original branch keeps serving its existing connections unchanged, while the restored branch receives separate compute and its own connection string.

The design removes the need to copy the full database into a new volume before it can be queried. Databricks says the result is a restored 100 TB database available in seconds. That figure is a company claim; the announcement provides neither an independent benchmark nor test methodology. It also distinguishes reaching an addressable past state from validating the data an application will read.

Lakebase separates stateless Postgres compute from a durable storage layer built from safekeepers, pageservers and cloud object storage. Compute sends write-ahead log records, or WAL, to safekeepers, while pageservers use that history to reconstruct database pages at a requested log sequence number. During a restore, Databricks says its control plane maps the chosen timestamp to the corresponding log sequence number, creates a branch pointing to the existing immutable history and then attaches compute.

The branch is a copy-on-write metadata operation. It represents the complete logical database state at the restore point while sharing the underlying stored history through pointers. Separate data is recorded only as the new branch changes. This differs from PostgreSQL’s documented continuous-archive recovery process, which restores a file-system backup and replays archived WAL to the target point.

Lakebase creates a new root branch rather than changing the source branch in place. The restore covers every Postgres database on the selected branch, and an application must be reconfigured to use the restored branch. Databricks’ documentation says the project-wide history window defaults to seven days and can be set from two to 30 days.