> Full Neon documentation index: https://neon.com/docs/llms.txt

# What tools enable temporary Postgres environments for each developer?

## Short answer

Neon's [branching](https://neon.com/docs/introduction/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.

```bash
# 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](https://neon.com/docs/introduction/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](https://neon.com/docs/introduction/plans#extra-branches).

## Auto-cleaning ephemeral branches

For CI and short-lived environments, set a [time to live](https://neon.com/docs/guides/branch-expiration) so the branch deletes itself:

```bash
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.

**Tip: Branches in CI**

Use the [Neon GitHub Action](https://neon.com/docs/guides/branching-github-actions) 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.CreatingConnecting.PostgreSQL.html)).
- **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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html)).
- **Supabase**: [Preview branches](https://supabase.com/docs/guides/deployment/branching) 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](https://supabase.com/docs/guides/platform/manage-your-usage/branching)).

> **Give every developer their own database**
>
> Branching is included on every Neon plan, free and paid.
>
> [Sign up](https://console.neon.tech/signup)