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 connection (the hostname containing -pooler) is transaction-mode PgBouncer, which breaks pg_dump the same way Supabase's transaction pooler does. Take the direct connection string (no -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