Rebuilding Prisma Postgres Backups: From Snapshots to Point-in-Time Recovery

[rtbenfield]

Summary

New blog post covering the Prisma Postgres backup migration from pg_basebackup to pgBackRest, with a per-database bucket storage layout on Tigris.

Covers:

• Why the old pg_basebackup system's recovery point and restore path were bounded by full-copy snapshots
• What pgBackRest's continuous WAL archiving changes for recovery point and restore time
• The Postgres extension's role in triggering backups over SQL from inside the database VM
• The one-bucket-per-database storage design and why Tigris was the right fit
• What this unlocks for users: point-in-time recovery and database forks that carry their full backup history

Test plan

• Technical accuracy review (backup/storage team)
• Voice and tone review
• DevRel sign-off
• Hero/meta images still need to be generated and added
• Verify all links resolve

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
blog	Error		Jul 16, 2026 11:18am
docs	Ready	Preview, Comment	Jul 16, 2026 11:18am
eclipse	Ready	Preview, Comment	Jul 16, 2026 11:18am
site	Ready	Preview, Comment	Jul 16, 2026 11:18am

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 471f1317-00db-4def-8800-90741427e582

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[argos-ci]

The latest updates on your projects. Learn more about Argos notifications ↗︎

Build	Status	Details	Updated (UTC)
default (Inspect)	✅ No changes detected	-	Jul 16, 2026, 11:23 AM

[ankur-arch]

Thanks for the write-up @rtbenfield!

I ran this past the doc writer skills to see how we can improve the blog to be more customer facing and it passed this feedback:

What’s great

• The engineering problem is clear. The article explains why the old backup architecture became expensive and slow to operate.
• The pg_basebackup vs pgBackRest example works well. The 100 GB database changing by only 10 MB a day makes the waste easy to understand.
• “The restore VM is the database” is a strong line and clearly explains the simplification.
• The one-bucket-per-database approach is interesting and shows a thoughtful isolation model.
• The Tigris section feels relevant because it explains which capabilities made the design possible.

What could be improved

• Lead with the customer value, not the VM architecture.

  This could open with:

  A bad migration or accidental deletion should not cost you hours of data. We rebuilt Prisma Postgres backups so databases can recover to a specific point in time, with recovery points measured in seconds or minutes instead of up to 12 hours.

• Make it clearer what is available now and what is coming later. The TL;DR makes point-in-time recovery sound live, but the article later says the user-facing restore flow is coming soon.

• The TL;DR should focus more on user outcomes.

  For example:

  • Reduce potential data loss from up to 12 hours to seconds or minutes
  • Recover to a point before a bad migration or accidental deletion
  • Restore databases faster through a simpler recovery path
  • Create forks that keep the source database’s backup history

• Add restore benchmarks if we have them. The article explains why restores are faster, but not how much faster.

  This line could be:

  In our internal tests, removing the recovery VM reduced restore startup time from X to Y for a Z GB database.

• “Recovery point measured in seconds” feels slightly too strong because the body says it can take a few minutes depending on write volume.

  This could be:

  Recovery points measured in seconds or minutes instead of up to 12 hours.

• Bring the bad migration example earlier. It is the clearest reason a user should care.

  For example:

  If a migration deletes production data at 14:32, Prisma Postgres can restore the database to the moment before it ran instead of falling back to a snapshot from hours earlier.

• Explain WAL in simpler terms before going deeper.

  For example:

  Base backups provide the starting state, while WAL archives record every change after that. Together, they let us rebuild a database at a specific moment.

• The “What this unlocks for users” section should be more specific.

  “Forks get more useful” could be:

  Fork a database from a point before a failed migration or bad SQL script, then investigate the issue without touching production.

• Be careful with this line:

  The 100 GB database that writes 10 MB a day finally pays a price closer to 10 MB.

  It sounds like a direct customer pricing change. If this is about internal storage and transfer costs, say that directly.

• The ending should connect agents to a real workflow instead of ending on a broad AI claim.

  For example:

  Soon, developers and coding agents will be able to create an isolated database from the moment before a failed migration, test a fix, and investigate the issue without touching production.

Overall

The engineering story is strong. The main improvement is to connect each architectural decision back to a customer outcome: less data loss, faster recovery, safer debugging, and more useful database forks.