neon instant restore is excellent — and still not a backup strategy

neon instant restore is one of the nicer things to happen to postgres operations in a while. restoring or branching to a past moment in seconds, no waiting on a dump to replay — it genuinely changes how you handle a bad deploy. this post is not a knock on it. keep it on.

it's a caution about a specific reflex: the better a provider's recovery feature is, the easier it is to quietly file it under "backups, handled" and stop thinking. instant restore is good enough to trigger that reflex, and it is not the same category as a backup.

recovery is not the same as a backup

here's the line that matters. a *recovery feature* lets you move your database to a previous state. a *backup* is a copy of your data that exists somewhere else, that you can restore from without the original system's cooperation. those overlap in casual usage and come apart completely on the bad day.

instant restore is a recovery feature. it's fast and it's elegant, but it operates inside neon, on data neon holds, reachable only while neon is reachable. that is the definition of a thing in the same trust boundary as your primary. it answers "i need to undo something," beautifully. it does not answer "i need a copy that survives neon having a bad day."

the questions it can't answer

run the same test you'd run on any provider-native feature:

- if the problem is the provider — an account issue, a billing lapse, a region event, a suspension — can you still reach the restore? no, because it lives where the problem is. - can you hand an auditor an independent, verifiable artifact proving you tested a restore from an off-box copy? no — "instant restore is available" is a feature of your plan, not evidence you produced. - does it keep a copy beyond neon's retention window, on storage you control? no — retention is whatever the provider offers.

none of these are failings of instant restore. they're just outside what a provider-internal feature can structurally do. asking it to be your backup is asking the wrong layer.

both, not either

the healthy setup is two layers. instant restore for "i made a mistake and want to undo it fast" — it's better at that than an external tool will ever be. and an independent, owned copy for "the provider had a bad day" and "prove it to my auditor." teams get into trouble when they let an excellent recovery feature stand in for the independence layer, because the gap is invisible until the exact moment it isn't.

where walwarden fits

walwarden is the independence layer, and only that. scheduled logical backups of your neon (and supabase) 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 or instant rewind. keep neon instant restore on for that — it's genuinely better at it. walwarden is the copy that's still yours, and still provable, when the question stops being "can i undo this" and becomes "is it even mine." the two complement each other; neither replaces the other.

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