Lakebase Postgres Uses Branches to Restore 100 TB in Seconds

Databricks says traditional managed OLTP restores can take hours because recovery requires provisioning compute, downloading snapshots and replaying WAL files. [1] Lakebase Postgres instead decouples compute and storage, retaining immutable database history in object storage so it can be referenced without copying data to a new disk. [1] A restore creates a branch at the selected timestamp through a metadata operation rather than a multi-hour copy-and-replay process. [1] According to Databricks, this reduces restore time to seconds even for a 100 TB database and lets AI agents handle branching and undo workflows. [1]

The architectural distinction is more important than the headline restore time: Lakebase avoids the provisioning, snapshot-download and WAL-replay sequence that makes traditional managed OLTP recovery slower as databases grow. That design also turns restoration into a branch operation, making recovery and undo easier to incorporate into automated agent workflows. The comparison, however, comes from Databricks rather than an independent evaluation. What the sources don't address: whether seconds-long restores remain consistent across different production workloads, recovery timestamps and failure conditions.