Neon’s branching and history are genuinely useful, and its point-in-time restore covers a lot. But it all lives inside your Neon project. For anything important, you want a copy somewhere else, on your own retention, that you can restore even if your Neon account isn’t available. And you want to know it actually restores, not just that a dump ran.
Norcube Backup does both: an independent copy in storage you own, restore-tested on every run.
What it does
Point Norcube at your Neon database. On your schedule it runs a full pg_dump, encrypts the archive, and writes it to a bucket you control. You can download any backup and restore it with standard Postgres tools, independent of Neon and of us.
Connecting Neon
One Neon-specific detail: use the direct (unpooled) connection string, not the pooled one. Neon’s pooled endpoint routes through PgBouncer in transaction mode, which doesn’t work with pg_dump. In the Neon Connect dialog, turn off connection pooling and copy the direct string (the host without -pooler). Neon requires SSL, so keep sslmode=require. A fresh Neon database is reachable with just the password; if you’ve enabled Neon’s IP Allow, add Backup’s egress IP 18.196.207.101. Full steps are in the Neon backup guide.
Prove it restores
Every backup can be restore-tested: Norcube restores it into a throwaway database and confirms your data comes back. Neon’s own platform extensions (neon, neon_utils) exist only on Neon’s compute, so a restore test recognizes their absence as expected and still records a clean pass. Your schemas, tables, and rows are what it proves came back.
Backups are only real once you’ve restored one
An independent, restore-tested copy of your Neon database in your own storage is worth setting up before you need it. Try it on your database, or read the Neon backup guide first.