Databricks Lakebase Postgres restores a 100 TB database in seconds with branches

Why traditional restores are slow

Databricks argues that restores in managed OLTP systems have always been slow and get slower as databases grow. The company says this leaves large production databases, where downtime is most costly, waiting the longest to recover.

The cause, according to Databricks, is the architecture. Compute and storage ship as one machine, so a point-in-time recovery (PITR) in a service such as Amazon RDS involves three steps:

• Deploy a new instance with compute and storage volumes at least the size of the primary. Large instances with large EBS volumes usually take longer to come up.
• Restore the latest usable snapshot from object storage. RDS makes the instance available before the data is local, so queries that touch a block not yet on the volume fetch it from S3 on the spot. Databricks says that latency is fine for an internal check but not for production.
• Replay WAL from the snapshot up to the target time. The amount of replay depends on how much happened between the snapshot and that moment.

Databricks states that unless the database is small, PITR is almost always a multi-hour operation. A high availability replica can help if a machine dies, but not when a dropped table or bad write has already reached the standby.

What a survey of Postgres users found

Databricks cites a survey of 50 developers running production Postgres databases of 1TB or more. According to the results it reports:

• 59% had a critical production failure in the past 12 months.
• 30% were down for 3+ hours, and some went past half a day.
• Only 21% recovered in under 60 minutes.

On business impact, 40% reported significant business interruption and 52% saw negative customer feedback. Some 72% felt only "somewhat confident" they could recover quickly if a failure happened again.

How branch-based restores work in Lakebase

In Lakebase, compute and durable storage are separate and connected by the WAL. Compute runs Postgres tasks such as SQL, query planning, MVCC, locking and WAL generation, but does not own the durable copy of the data. Storage is split across three components:

• Safekeepers receive WAL from compute. A transaction is durable once a quorum of safekeepers acknowledges its WAL record.
• The pageserver turns WAL into the pages Postgres reads and can reconstruct any page at a given LSN.
• Object storage keeps the immutable, long-term history.

Because old page versions are never overwritten, the database history builds up as a timeline that can be addressed. A restore is then a branch at a point in that history. The branch has its own independent compute and its own connection string, and it can be queried independently of production.

The process, as Databricks describes it: when something fails on the main branch, the user picks a past timestamp and can inspect it by running queries before committing. The control plane then maps the timestamp to the exact LSN, creates the branch and attaches compute. The restored branch points at image and delta layers that already exist, so no data is copied.

What it means for users

Databricks says that because a restore is metadata work, its duration does not depend on database size, so restoring 100 TB is as fast as restoring 10 GB. The company also says the operation is simple enough for an AI agent to carry out, supporting branching and undo workflows. For teams running large Postgres databases, the claim is that recovery would no longer require extra replicas, extra environments or hours of downtime. These performance figures come from Databricks and are not independently verified in the source.