---
title: "Lakebase Postgres branch-based restores for fast recovery at scale"
description: "Traditional Postgres point-in-time recovery is slow because compute and storage are coupled, requiring provisioning a new instance, restoring a snapshot from object storage to disk, and replaying WAL, leading to hours of downtime for large databases. In a survey of developers running 1TB+ production Postgres, 59% had a critical production failure and 30% were down for over three hours. Lakebase Postgres decouples compute and storage using safekeepers, a pageserver, and object storage, storing database history as an immutable timeline. A restore becomes a branch at a point in history, a metadata operation that does not copy data, making it near-instant regardless of database size. This eliminates data copies and WAL replay, so restoring a 100 TB database is as fast as restoring 10 GB, and agents can use restores as ordinary tool calls for versioning and undo."
---

# Lakebase Postgres branch-based restores for fast recovery at scale

[Databricks](https://yomu.fyi/company/databricks) · Cassie Murray, Carlota Soto · Oct 1, 2026

**Type:** Explainer

## Summary

Traditional Postgres point-in-time recovery is slow because compute and storage are coupled, requiring provisioning a new instance, restoring a snapshot from object storage to disk, and replaying WAL, leading to hours of downtime for large databases. In a survey of developers running 1TB+ production Postgres, 59% had a critical production failure and 30% were down for over three hours. Lakebase Postgres decouples compute and storage using safekeepers, a pageserver, and object storage, storing database history as an immutable timeline. A restore becomes a branch at a point in history, a metadata operation that does not copy data, making it near-instant regardless of database size. This eliminates data copies and WAL replay, so restoring a 100 TB database is as fast as restoring 10 GB, and agents can use restores as ordinary tool calls for versioning and undo.

## Context

Traditional managed OLTP restores are slow because compute and storage are coupled, requiring provisioning a new instance, restoring a snapshot from object storage to disk, and replaying WAL. A survey of developers with 1TB+ Postgres found 59% had a critical production failure and 30% were down for over three hours.

## Approach / What changed

Lakebase Postgres decouples compute and storage. Safekeepers receive WAL from compute and acknowledge durability. Pageserver turns WAL into pages and stores immutable history in object storage. A restore creates a branch at a timestamp, a metadata operation that does not copy data. Compute is attached to the branch, making the restored database available instantly regardless of size.

## Takeaways

- Traditional Postgres PITR requires provisioning a new instance, restoring a snapshot from object storage to disk, and replaying WAL, leading to multi-hour downtime for large databases.
- Lakebase Postgres stores database history as an immutable timeline, so a restore is a branch at a point in history, a metadata operation that does not copy data.
- Branch-based restores are fast enough that agents can use them as ordinary tool calls, enabling features like versioning and undo in platforms such as Replit or v0.

## FAQ

### How does a Lakebase restore differ from traditional PITR?

Traditional PITR copies data from a snapshot and replays WAL, taking hours. Lakebase creates a branch at a timestamp, a metadata operation that does not copy data, making it near-instant.

### Why are traditional Postgres restores slow?

Because compute and storage are coupled, requiring provisioning a new instance, restoring a snapshot from object storage to disk, and replaying WAL, each step taking time that grows with database size.

### Can agents use Lakebase restores?

Yes, because restores are simple metadata operations, agents can treat them as ordinary tool calls, enabling features like versioning and undo in platforms such as Replit or v0.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Databases](https://yomu.fyi/topic/databases), [Object Storage](https://yomu.fyi/topic/object-storage), [Postgres](https://yomu.fyi/topic/postgres)

- Source: [Databricks](https://www.databricks.com/blog/lakebase-postgres-branch-based-restores-fast-recovery-scale)
- Source URL: https://www.databricks.com/blog/lakebase-postgres-branch-based-restores-fast-recovery-scale
- Ingested by Yomu: 2026-10-01T21:00:07.296Z

[Read original post](https://www.databricks.com/blog/lakebase-postgres-branch-based-restores-fast-recovery-scale)