<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale-gvio7wglc" -->

---
title: Lakebase Postgres branch-based restores for fast...
description: Databricks explains how Lakebase Postgres replaces traditional point-in-time recovery with branch-based restores. Traditional managed Postgres (e.g., Amazon...
canonical: https://daily.dev/posts/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale-gvio7wglc
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Lakebase Postgres branch-based restores for fast recovery at scale | daily.dev
og:description: Databricks explains how Lakebase Postgres replaces traditional point-in-time recovery with branch-based restores. Traditional managed Postgres (e.g., Amazon...
og:url: https://daily.dev/posts/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale-gvio7wglc
og:image: https://api.daily.dev/og/posts/gvio7WgLc.png
og:image:alt: Lakebase Postgres branch-based restores for fast recovery at scale
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

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

**[databricks](https://daily.dev/sources/databricks)** · 7 min read · 0 upvotes · 0 comments

## Summary

Databricks explains how Lakebase Postgres replaces traditional point-in-time recovery with branch-based restores. Traditional managed Postgres (e.g., Amazon RDS) couples compute and storage, so restores require provisioning a new instance, pulling snapshots out of S3, and replaying WAL, often taking hours for large databases. Lakebase decouples compute and storage, keeping database history in object storage as instantly referenceable image and delta layers. A restore becomes a metadata-only operation: creating a branch at a timestamp with its own compute and connection string, with no data copying involved. This makes restore time constant regardless of database size, enabling near-instant recovery of databases up to 100 TB and allowing agents or platforms like Replit and v0 to use branching as a routine tool call for versioning and undo features.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://www.databricks.com/blog/lakebase-postgres-branch-based-restores-fast-recovery-scale>

## Questions this post answers

### Why is point-in-time recovery so slow on Amazon RDS for large Postgres databases?

Because compute and storage are coupled, so a restore first provisions a new instance sized like the primary, then pulls the snapshot out of S3 onto the volume, then replays WAL from snapshot time to the recovery timestamp. Even though RDS marks the instance available before hydration finishes, queries touching non-local blocks fetch from S3 on demand, so the process can take hours on large databases.

_Teams evaluating Postgres recovery strategies can track architecture comparisons like this one on daily.dev._

### How does Lakebase Postgres make database restores fast even at 100 TB scale?

Lakebase decouples compute from durable storage and keeps database history as already-referenceable image and delta layers in object storage, so a restore is simply creating a branch at a timestamp, a metadata operation rather than a copy-and-replay job. This gives independent compute and a connection string with no data movement, making restore time constant regardless of database size.

_Engineers weighing database architectures for recovery speed can follow coverage of approaches like this on daily.dev._

## Similar posts on daily.dev

- [Inside branch-based restores in Lakebase Postgres](https://daily.dev/posts/inside-branch-based-restores-in-lakebase-postgres-udhwx0m8z) · Neon · 1 upvotes · 1 comments
- [Backstage with Lakebase](https://daily.dev/posts/backstage-with-lakebase-15djpmigs) · databricks · 0 upvotes · 0 comments
- [Database Branching in Postgres: Git-Style Workflows with Databricks Lakebase](https://daily.dev/posts/database-branching-in-postgres-git-style-workflows-with-databricks-lakebase-hdnh9bdho) · databricks · 23 upvotes · 0 comments
- [WAL \+ S3: Lakebase storage for the era of agents](https://daily.dev/posts/wal-s3-lakebase-storage-for-the-era-of-agents-4trqspanr) · Neon · 25 upvotes · 2 comments

---

Tags: [#postgresql](https://daily.dev/tags/postgresql), [#databricks](https://daily.dev/tags/databricks)

[View this post on daily.dev](https://daily.dev/posts/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale-gvio7wglc)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Lakebase Postgres branch-based restores for fast recovery at scale","url":"https://daily.dev/posts/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale-gvio7wglc","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale-gvio7wglc"},"datePublished":"2026-10-01T18:57:47.348Z","dateModified":"2026-10-01T19:00:55.859Z","description":"Databricks explains how Lakebase Postgres replaces traditional point-in-time recovery with branch-based restores. Traditional managed Postgres (e.g., Amazon...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/58546810966340f38c7d145fa15882ef?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/58546810966340f38c7d145fa15882ef?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"databricks","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"databricks","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/fa7aa720f2db4d1eba826814730482c8","url":"https://daily.dev/sources/databricks"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale-gvio7wglc","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"postgresql,databricks","timeRequired":"PT7M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"databricks","item":"https://daily.dev/sources/databricks"},{"@type":"ListItem","position":3,"name":"Lakebase Postgres branch-based restores for fast recovery at scale"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale-gvio7wglc#faq","mainEntity":[{"@type":"Question","name":"Why is point-in-time recovery so slow on Amazon RDS for large Postgres databases?","acceptedAnswer":{"@type":"Answer","text":"Because compute and storage are coupled, so a restore first provisions a new instance sized like the primary, then pulls the snapshot out of S3 onto the volume, then replays WAL from snapshot time to the recovery timestamp. Even though RDS marks the instance available before hydration finishes, queries touching non-local blocks fetch from S3 on demand, so the process can take hours on large databases. Teams evaluating Postgres recovery strategies can track architecture comparisons like this one on daily.dev."}},{"@type":"Question","name":"How does Lakebase Postgres make database restores fast even at 100 TB scale?","acceptedAnswer":{"@type":"Answer","text":"Lakebase decouples compute from durable storage and keeps database history as already-referenceable image and delta layers in object storage, so a restore is simply creating a branch at a timestamp, a metadata operation rather than a copy-and-replay job. This gives independent compute and a connection string with no data movement, making restore time constant regardless of database size. Engineers weighing database architectures for recovery speed can follow coverage of approaches like this on daily.dev."}}]}
```

