Database Backups That Actually Work in 2026

Backups exist to be restored. The backup that's never been restored has the same value as no backup at all. This piece is what to set up, what each kind of backup actually buys, and the quarterly drill that proves the system works.

RTO and RPO, briefly#

• RPO (Recovery Point Objective): how much data loss is acceptable. "Up to 5 minutes" vs "up to 24 hours".
• RTO (Recovery Time Objective): how long the restore can take. "Under an hour" vs "same day".

Pick both numbers consciously. They drive what kind of backup strategy you need.

Point-in-time recovery (PITR)#

The gold standard. A continuous archive of WAL (write-ahead log) segments lets you restore to any point in time within your retention window.

How it works: a base backup (a snapshot of the data directory) plus every WAL segment since. To restore: replay the base backup, then the WAL up to your chosen point.

RPO with PITR is typically seconds-to-minutes; RTO depends on database size and how far back you replay.

• Supabase: PITR included on Pro tier with 7-day retention; up to 30 days on Team.
• Neon: continuous WAL archive with up to 30-day point-in-time restore.
• RDS: PITR via automated backups; retention configurable.
• Self-hosted: pgBackRest, Barman, or WAL-G + S3.

Logical dumps (pg_dump)#

pg_dump produces a SQL or custom-format file that recreates the database from scratch. Cheap to generate, very portable, but:

• Locking and load. A dump on a hot database can move significant IO. Schedule off-hours or against a replica.
• Restore time scales with database size: gigabytes of data take tens of minutes; terabytes take hours.
• The dump is consistent at the moment it starts (default), not at the moment it finishes. Subsequent writes are lost.

# Daily logical dump of one database, custom format, compressed.
pg_dump --format=custom --compress=9 --file=/backups/db-$(date +%F).pgdump \
  "postgres://user:pass@host/dbname"

We keep pg_dump in the toolbox for two reasons: it's a clean restore target across Postgres major versions (PITR is version-locked), and it's a good archive format that you can keep off-platform.

Storage snapshots#

Block-level snapshots from your storage provider (EBS, persistent disks, Supabase's underlying volume). Fast to take, near-zero impact on the running database.

The catch: a snapshot of a running Postgres includes in-flight memory state that's not on disk yet. Restoring from a raw snapshot leaves Postgres to recover from WAL on startup, which works but is a hair scarier than PITR.

Snapshots are great for the "clone production to staging" flow. For disaster recovery, prefer PITR.

What managed providers actually give you#

The 2026 baseline across the popular providers:

• Supabase Pro: 7-day PITR included. Daily logical backups for 7 days. Point-in-time restore lands a new project.
• Neon: continuous archive; up to 30 days PITR on Scale plan. Branching also works as backup-as-time-travel.
• RDS: 1-35 day automated backups; manual snapshots on demand.
• Crunchy Bridge: 14-day PITR by default; longer retention via S3 archive option.

The restore drill#

The most important practice: actually restore from backup, quarterly, end-to-end. It's the only thing that proves the system works.

1. Take a snapshot of a known state. Note the timestamp.
2. Make a change you can recognise (insert a row, alter a column).
3. Restore to the noted timestamp into a separate database.
4. Verify the change isn't there.
5. Time the whole thing. That's your real RTO.

Do this with your team watching. Write down where the friction is. Fix it next quarter. By the time you actually need to restore from backup, the team has done it three times.