self-hosting postgres backups after pgBackRest — what people are actually reaching for

pgBackRest getting archived in april sent a lot of teams looking for the exit. the reasonable next question — "what do we use now?" — has a better-than-average answer, but only after you answer a question most of the migration threads skip: are you actually self-hosting postgres, or are you renting it from supabase, neon, or rds?

because those are two different worlds, and pgBackRest only ever lived in one of them.

if you self-host postgres

pgBackRest did physical backups: base backups plus wal archiving, with point-in-time recovery on top. that's the real machinery, and if you run your own postgres you still want it. the live successors are roughly:

- **wal-g** — physical backups + wal archiving to object storage, actively maintained, the most common pgBackRest replacement people land on. - **pgmoneta** — newer, also physical + wal, growing. - **barman** — long-standing, still maintained, more of a backup-server model.

if what you valued in pgBackRest was physical base backups and point-in-time recovery, one of those is your move. that's not the part of the problem walwarden solves, and we'll say so plainly.

if you rent postgres

here's the thing the archival made visible: a large and growing share of teams aren't self-hosting at all. they're on supabase or neon, and pgBackRest was never an option for them — you can't run base backups and wal archiving against a database whose filesystem you don't have. for those teams "pgBackRest is gone" is a non-event, because it was never in the toolbox.

what *is* in their toolbox is usually a `pg_dump` in a github action and a quiet hope. logical, not physical. and that's actually the right primitive for rented postgres — the gap isn't the dump, it's everything around it: is the copy somewhere you own, is it tamper-evident, did anyone test a restore, is there a record.

where walwarden fits, honestly

walwarden is the second world, not the first. scheduled logical backups of the postgres you run on supabase and neon, written to object storage you own, each copy signed and recorded in an append-only audit chain, with operator-run restores through a cli on your machine. aws rds/aurora is on the roadmap.

what we deliberately don't do: physical backups, wal archiving, or point-in-time recovery. no second-by-second rewind — not yet, and we won't claim it as shipping before it's real. if you need that machinery, you're in the self-host world above and wal-g is a better fit than we are today.

the honest pitch is narrow on purpose: if you rent your postgres and what you actually need is a recoverable, provable copy you own — not a fork of a tool you never wanted to operate — that's the thing we ship.

the roadmap is exactly what runs today, /proof is a signed bundle you can verify yourself, and start free is one database away.