Copy-and-Replay vs Branch-at-a-Point: Two Backup Recovery Paths
A side-by-side comparison of copy-and-replay recovery and branch-at-a-point restores, showing why restore time scales with data size in one model and not the other.
Loading post…
DatabricksCassie Murray, Carlota SotoExplainer
Lakebase Postgres branch-based restores for fast recovery at scale
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.
Source and freshness
- Source
- databricks.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
Visual explainers
How AWS CloudFormation Turns a Template Into a Reconciled Stack
CloudFormation is a declarative reconciler: you describe the target state in a template, and it provisions, updates, and reports on the stack that results. Here is the loop.
Asset Management's Four Layers: From Custodian File to Signed NAV
Asset management runs as a layered control plane: custodian and pricing data feed a governed context layer, agents run the overnight fund work, and a human signs off before anything is published.
Amazon EVS Architecture: Where vSAN Ends and FSx for ONTAP Begins
Amazon EVS runs VMware Cloud Foundation on AWS bare metal, so the design question becomes where each workload's data lives. This layered diagram shows how vSAN, FSx for ONTAP, and cross-Region DR divide the work.
How to give every agent its own versioned workspace
A five-step workflow for turning agent output into versioned artifacts: scope a repo per agent, branch instead of copying, run in an isolated sandbox, gate changes with push-triggered evals, then deploy or roll back.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.