backup independence — who owns your bytes when your provider has a bad day

"do you have backups" is the wrong question. the question is who can reach them on a bad day, and whether that includes you.

most managed-postgres backups are a feature of the database, not a thing you hold. supabase and neon both keep solid backups — inside their own account, in their own format, restorable through their own console. on a normal tuesday that's fine. the trouble is that backups are not for normal tuesdays.

the dependency you don't notice until you need it

think about when you actually reach for a backup. it's never a calm moment. and the bad-day list has a pattern to it:

- an incident is in progress and the dashboard you'd restore from is the thing that's degraded. - a billing lapse or a payment-method problem quietly locks the account, and the lock is in front of the backups too. - you open a support ticket and the answer that matters is two business days out. - a region event takes the primary and the backups sitting next to it at the same time. - an account gets suspended, or a key gets compromised, and access to everything — including recovery — goes through the same door that's now stuck.

none of these are exotic. and in every one, the recovery you need is behind the same wall as the problem. a backup you can only reach by asking the provider nicely is not insurance against the provider.

what "independence" actually means

backup independence is a boring, literal idea: the copy lives somewhere you control, and you can restore from it without the provider's cooperation.

concretely, that's a copy in storage you own — your own s3 bucket, your aws account, your bill, your access keys. the provider that hosts your database has no role in reaching it. if they have a bad day, a bad quarter, or no more days at all, the bytes are still yours and `pg_restore` still works.

"a copy somewhere else" is necessary but not sufficient. a second copy you can't verify is just a second thing to worry about. independence that holds up means four things together:

- **your account, your bucket.** not a vendor's storage with your name on it — storage you'd still have if the vendor were gone. - **keys you hold.** encryption you control, so the copy is yours to read and no one else's. - **integrity you can check.** a signed manifest per copy, so you can trust the file is what it claims to be and hasn't been touched. - **a restore path that routes around the provider.** recovery that runs from your storage on a machine you control, not a button inside the console that might be the thing that's down.

own the bucket, hold the keys, sign the copy, keep the restore path independent. that's the whole idea.

what we ship, and what we don't

this is what walwarden is: 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. restores run through a cli on your machine, pulling straight from your bucket. aws rds/aurora is on the roadmap.

what we don't claim: point-in-time recovery. no second-by-second rewind yet, and we won't print the word before it's real. what ships today is a copy you own and can prove — which is the part of "backup" your provider was never going to sell you.

if you've ever thought through what actually happens on the bad day: the roadmap is what ships now, /proof is a real signed bundle you can verify yourself, and you can start free on one database.