THE MAP / NEON POSTGRES BACKUP

Neon Postgres backup: the complete picture

THE HISTORY WINDOW · WHY BRANCHES AREN'T BACKUPS · OWNING YOUR COPY

Neon's architecture is genuinely clever — storage and compute are separated, history is retained continuously, and any point in the window can become a live branch in seconds. That cleverness is also why Neon users skip backups more confidently than anyone else: it feels covered. Here's precisely what is and isn't.

What Neon gives you natively

Why a branch is not a backup

A branch is a bookmark into the same storage — same platform, same project, same account, same blast radius. It cannot be downloaded, cannot outlive the account, expires with the history window's economics, and has never been proven to restore as an independent artifact. Branching protects you from your own mistakes inside the window; it does nothing against a locked account, a billing lapse, a platform incident, or any need to reach back further than the window. Those need a copy that leaves the building.

The three gaps the window doesn't close

Your options, honestly

History window alone

  • Excellent recovery inside its range, zero setup.
  • On-platform only; bounded by days; nothing exportable or proven.
  • Fine pre-revenue, or when the data is replaceable.

DIY pg_dump cron

  • Free; works against the unpooled endpoint; you own the copies.
  • Silent failures, key management, and untested restores — forever.
  • Honest comparison: OffsiteDB vs a cron job.

Window + automated off-site

  • Keep Neon's window for fast in-platform recovery.
  • Encrypted dumps to your own S3/R2/B2 bucket, restore-drilled and row-counted.
  • Retention in months, tagged pre-migration checkpoints, monthly drill reports.

Set it up: Neon to a bucket you own

Each guide covers the Neon-specific gotchas — the pooled-vs-unpooled endpoint trap, sslmode=require, and a one-command restore:

Doing it by hand? The pg_dump generator writes the right flags, and the RTO/RPO calculator puts numbers on your current exposure.

Five minutes to a proven copy

Paste your unpooled Neon connection string, point it at your bucket, and the first encrypted, restore-drilled snapshot runs in minutes. Start free, poke at the live demo, or see the restore-drill report you'd be forwarding to auditors.

FAQ

Does Neon back up my database automatically?
Neon continuously retains a history window you can restore (or branch) from — roughly a day on the free plan, longer on paid tiers. Within that window, recovery is excellent. Outside it, the data is gone, and everything lives inside Neon's platform and your Neon account.
Isn't Neon's branching basically a backup?
No — and this is the most important Neon-specific fact. Branches are copy-on-write views over the same underlying storage, in the same project and account. They're superb for dev/test and quick rollbacks inside the history window, but they can't survive account loss or a platform incident, can't be exported, and were never restore-tested as archives. A branch is a bookmark, not a copy.
Which Neon connection string do I use for pg_dump?
The direct (unpooled) endpoint. Neon's pooled connection string runs PgBouncer in transaction mode, which pg_dump can't use. Keep ?sslmode=require on the URL — Neon requires SSL.
Do Neon's native features protect me from a bad migration?
Within the history window, yes — you can restore to just before the migration, which is genuinely better than daily snapshots. What's missing is everything outside the window, an exportable artifact, and proof: nothing tells you a recovery actually works until you try it. A tagged, restore-drilled checkpoint before each migration gives you the artifact and the proof.
What's the safest minimal setup for Neon?
Keep Neon's history window (it's free recovery superpowers within its range) and add an automated, encrypted off-site dump to your own S3/R2/B2 bucket with restore testing. The off-site layer covers what the platform structurally can't: account loss, long retention, and evidence that restores work.

Keep reading