supabase point-in-time recovery vs an off-supabase backup — a decision tree

supabase point-in-time recovery is a genuinely good feature. the mistake teams make is treating it as the same category as "do we have backups," when it answers a different question. both can be true at once, and you usually need both — but for different bad days.

here is the distinction that resolves most of the confusion: **pitr rewinds your database to a moment, inside supabase, from data supabase holds. an off-supabase backup is a copy in storage you own, that you can restore without supabase in the loop at all.** same word, "recovery," two different trust models.

when supabase pitr is the right tool

if the bad day is a *mistake* — someone dropped a table, a migration went sideways, an app bug wrote garbage for twenty minutes — pitr is exactly what you want. it's fast, it's granular, and it's right there in the console. you trust supabase to be up and to be holding your data; you just need to step back in time a little. for that shape of problem, an external dump is slower and clumsier and you should reach for pitr.

when it isn't enough

pitr shares a property with the database it protects: it lives inside supabase, restores through supabase, and depends on supabase being reachable and intact. that's fine right up until the thing you're worried about *is* the provider — an account lock, a billing problem, a region event, a suspension. on those days the rewind button is behind the same wall as the outage.

it's also not an evidence trail. a soc 2 auditor asking for proof of a tested restore from an independent copy is not satisfied by "we have pitr enabled" — that's a provider setting, not a verifiable artifact you produced and can hand over. and pitr's retention is whatever window the provider gives you, which may be shorter than what your retention policy commits to.

the decision tree

it really is this short:

- **is your risk "we made a mistake"?** → supabase pitr. keep it on, it's great. - **is your risk "our provider had a bad day" or "our auditor wants proof"?** → an off-provider backup you own, with a restore record. pitr can't reach either of those.

most serious teams answer *yes to both*, on different days. that's the tell that these aren't substitutes — they're two layers. the failure mode is assuming the provider feature covers the independence question. it structurally can't.

where walwarden sits

walwarden is the second layer, and only the second layer. scheduled logical backups of your supabase (and neon) postgres into 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 don't do, and won't claim: point-in-time recovery. no second-by-second rewind — keep supabase pitr on for that; it's better at it than we would be. walwarden is the off-box copy and the evidence, the thing that's still yours on the day supabase isn't reachable or the auditor wants a bundle. it complements pitr; it doesn't replace it.

the roadmap is what ships today, /proof is a signed bundle you can verify offline, and start free covers one database.