Shared staging databases are a contention problem: one developer's migration breaks another developer's feature branch, and the team queues up behind whoever ran a destructive query last. Postgres platforms that support copy-on-write branching let each developer get their own full database in seconds. On Neon, that's a first-class feature, and idle branches cost $0 in compute.
Why branches replace shared staging
A Neon branch is a copy-on-write clone of another branch. When you create it, no data is copied: the new branch points to the parent's pages and starts diverging only as you write. That means:
- A new dev branch is ready to query in seconds, regardless of database size
- Storage on a child branch starts at $0 and grows only with writes on that branch
- The parent (production or main) is untouched and unaffected
Each developer can have their own branch, with their own connection string and their own compute. No more "did you run that migration on staging?"
Creating a dev branch
From the CLI:
neon branches create --name dev/alice --parent main
neon connection-string dev/aliceYou can wire this into onboarding so every new developer gets a branch automatically. Set a TTL if the branch is short-lived, or mark long-lived dev branches as protected to prevent accidental deletion.
Compute per developer
Each branch runs on its own compute, which scales to zero after 5 minutes of inactivity. So a team of ten developers with ten branches pays compute only for the hours each person actually queries. Cap autoscaling at 0.25 CU on dev branches and they can't exceed that ceiling, which keeps costs predictable.
Reset a branch instead of recreating it
Use reset from parent to pull the latest production state into a dev branch without changing its connection string. Your app keeps working, but the data is fresh.
Limits to know
- Free plan: up to 10 branches per project
- Launch: 10 included, additional branches at $1.50/branch-month (prorated hourly)
- Scale: 25 included, with the same overage pricing
How this compares to other providers
- Supabase branching gives each preview branch a full isolated environment (database, auth, storage, edge functions), but the branch does not start with any data from the main project. You seed it from a
seed.sqlfile. Each preview branch counts as its own project for compute billing. See Supabase branching. - Aurora PostgreSQL supports fast database cloning at the cluster level (copy-on-write), but each clone is a separate cluster with its own writer and reader instances to manage. There's no built-in per-developer workflow.
- RDS for PostgreSQL doesn't have copy-on-write. To give each developer a copy, you snapshot the production instance and restore it into a new instance, which takes minutes to hours depending on size, and each restored instance is billed as its own DB instance.
The practical difference is data continuity: a Neon branch starts as a full copy of production data and only diverges as developers write to it. Supabase branches start empty. AWS clones are full clusters to provision.

Branching is included on every Neon plan.








