Guide

Backing up Neon: what you have, what you don't

Neon's instant restore is excellent — inside its window. On the Free plan that window is measured in hours, and nothing Neon keeps is an offsite copy under your control.

What Neon gives you

• Instant restore (PITR): roll a branch back within your plan's history window. On Free that window is short (hours, not days); paid plans extend it.
• Branches: copy-on-write clones — great for dev and for testing restores, but they live in the same Neon project. A deleted project takes its branches with it.
• What you don't have: a copy outside Neon, in your own storage, restorable anywhere. That part is yours to build.

Export with pg_dump — use the unpooled string

Neon's pooled hostname (containing -pooler) is transaction-mode PgBouncer. Tested 2026-09-04: recent PgBouncer handles prepared statements, and a small dump through the pooler succeeded — but Neon still recommends the direct string for pg_dump, and so do we: long dumps on transaction pooling remain exposed to connection reassignment and timeouts. Take the string without -pooler in the host:

pg_dump -Fc -f "neon-$(date +%F).dump" \
  "postgresql://user:pwd@ep-xxx-123456.us-east-2.aws.neon.tech/neondb?sslmode=require"

Notes:

• A scale-to-zero compute wakes on connection — the first attempt may take a few extra seconds, that's normal.
• For big databases, schedule dumps when the compute is warm and watch your plan's data-transfer allowance.
• Ship the file to your own S3/R2/B2 bucket, encrypted, on a schedule (a GitHub Actions cron works fine).

Then prove it restores

Neon's own branches are a fair drill environment for logical dumps too, but the portable habit is a throwaway container — same tools you'd use in a disaster: the 5-step drill.

Related fixes: How to actually test a Postgres backup pg_restore version mismatches