Short answer

Neon's branching creates an isolated Postgres environment for each developer in about a second. Branches start as copy-on-write forks of your production data, so devs get realistic data without copying it. When the branch is deleted, the storage delta goes with it.

Creating a per-developer branch

The simplest pattern: one branch per developer, named after their Git handle or feature.

# Each developer runs this once
neon branches create --name dev/alex --parent main
neon connection-string dev/alex > .env.local

Now every developer has their own connection string in .env.local. Running migrations, seeding test data, or dropping the schema affects only their branch.

Why this is cheaper than dev databases on RDS

A traditional setup gives each developer a small RDS instance. Five developers at the smallest production-grade instance is around $50 to $100/month sitting idle on weekends.

On Neon, each branch shares storage with main until it diverges. You pay for the delta and for compute only while the branch is being queried. With scale to zero, an idle dev branch costs effectively nothing in compute. Extra branches beyond your plan's allowance are $1.50/branch-month (~$0.002/hr); see extra branches pricing.

Auto-cleaning ephemeral branches

For CI and short-lived environments, set a time to live so the branch deletes itself:

neon branches create --name pr-1234 --parent main --expires-at "$(date -u -d '+24 hours' +%Y-%m-%dT%H:%M:%SZ)"

Neon removes the branch at the expiration time. No script to write, no orphaned environments piling up.

Branches in CI

Use the Neon GitHub Action to create a branch on each pull request, run tests against it, and delete it on merge. The whole loop adds a few seconds to your CI job.

How other Postgres platforms compare for per-developer environments

  • AWS RDS for PostgreSQL: Each developer gets their own DB instance. There's no native concept of a copy-on-write branch, so realistic data per developer means snapshot-and-restore (which can take a long time on larger databases) or sharing a single dev instance. Instances run and bill continuously until stopped or deleted (RDS user guide).
  • AWS Aurora Serverless v2: One cluster per developer is possible, with auto-pause keeping idle clusters from billing. Spin-up still requires provisioning a new cluster from a snapshot, which is not the few-seconds workflow you get from a Neon branch (Aurora Serverless v2).
  • Supabase: Preview branches provide isolated environments per Git branch, but they don't carry production data; you seed each branch from a seed.sql. Branches bill as Compute Hours per branch (branching usage).
Give every developer their own database

Branching is included on every Neon plan, free and paid.