Neon has database features that most teams aren’t using. Branching, time travel, schema diff, scale-to-zero. I’ve been running Postgres in containers and on RDS for years and haven’t taken advantage of any of this, so I thought I’d take a proper look.
I’ve used Supabase before, which has some overlap, and Vercel uses Neon under the hood for their Postgres offering. AWS has serverless Postgres too - Aurora Serverless v2 is solid, and Aurora DSQL launched more recently, but when I tried DSQL it was rough around the edges and not ready for real use. Neon’s pricing is more competitive than all of them, especially after the price cuts in 2025.
Branching
Neon uses copy-on-write storage, so creating a branch of your database (schema and data) takes seconds regardless of size. No pg_dump, no waiting, no extra storage cost until you start writing to the branch.
production ●──────────●──────────●──────────●──────────→
│ │
├── preview/pr-42 ──× (merged, deleted)
│
├── test/ci-run ────× (passed, deleted)
│
└── dev ──→ (active)Practical uses:
Preview environments. Every PR gets its own database branch with real production data. Wire it up with a GitHub Action - branch is created when the PR opens, deleted when it merges. Vercel preview deployments can each point to their own branch.
Safe migrations. Create a branch, run your migration against it, verify everything works, then run it against production. If it breaks, the branch is disposable.
Testing with real data. Seed data is never realistic enough. A branch of production gives your test suite actual data to work against. Create it at the start of a CI run, tear it down at the end.
Anonymization. Branches can mask sensitive data with realistic fake values, so you get production-shaped data in dev without exposing real customer information.
Branches are also ephemeral by default - obsolete branches delete themselves automatically after the work is done.
# Create a branch from production
neonctl branches create --name pr-142 --parent main
# Get the connection string
neonctl connection-string pr-142
# Delete when done
neonctl branches delete pr-142Schema diff
Neon can compare schemas between any two branches and output the difference. This works in the CLI, the API, and as a GitHub Action that posts a diff summary as a PR comment.
# Compare a feature branch against main
neonctl branches schema-diff --base-branch main --branch pr-142The API endpoint (compare-schema) makes this available programmatically, which is useful for CI gates - fail the build if a migration introduces an unexpected schema change.
Scale to zero
Neon suspends compute after 5 minutes of inactivity. When a connection comes in, it spins back up. First connection after cold start takes a few hundred milliseconds.
For production with steady traffic this doesn’t matter - compute stays warm. For dev branches, staging environments, and side projects that get hit a few times a day, it means you’re not paying for idle compute.
The free tier gives you 100 compute-hours per month with unlimited branches. That covers a lot of development and testing without paying anything.
Time travel
Neon stores WAL records and can reconstruct your database at any point in time. Up to 30 days of retention on paid plans, 6 hours on free.
This isn’t just point-in-time restore. You can query your database as it was at a specific timestamp before deciding whether to restore. Neon calls this Time Travel Assist - you pick a time, browse the data, then decide.
-- Query your database as it was yesterday
-- (via a temporary branch at that point in time)
SELECT * FROM orders WHERE created_at > '2026-03-01'If someone accidentally deletes rows or a bad migration corrupts data, you can see exactly what the data looked like before it happened, create a branch from that point, and either restore or selectively copy what you need.
Autoscaling
Neon scales compute up and down based on load. You set a minimum and maximum, and it adjusts CPU and memory automatically. No manual intervention, no capacity planning.
On RDS, you pick an instance size and you’re stuck with it until you manually resize (which involves downtime or a failover). On Neon, a spike in traffic gets more resources automatically and scales back down when it passes.
The architecture behind it
Traditional Postgres ties compute and storage together. Neon separates them. The storage layer is independent - a Postgres compute node can be paused, scaled, or branched without moving data. This is what makes branching instant and scale-to-zero possible.
It’s also why logical replication works differently. Neon can replicate data out to warehouses, analytics platforms, or other Postgres instances. One thing to know - a compute with an active replication subscriber won’t scale to zero, and inactive replication slots get cleaned up after about 40 hours.
When it makes sense
Neon is a good fit for:
- Teams that want database branches for preview environments and CI
- Projects where you need real data in dev/staging without managing dumps
- Side projects and MVPs where scale-to-zero keeps costs near zero
- Any setup where you want point-in-time recovery without managing backups
One thing that blocked me from using Neon for production previously was security. The console only supported username and password login - no 2FA, no SSO. For a service holding production data, that wasn’t good enough. They’ve since added 2FA and HIPAA compliance, which removes that objection. The price drop in 2025 (storage went from $1.75 to $0.35 per GB) was the other missing piece. They’ve also made connection strings easy to grab from the console and have an MCP server that lets AI editors like Claude Code and Cursor interact with your database directly.
It’s not a replacement for every Postgres deployment. If you need full control over the Postgres instance, extensions that Neon doesn’t support, or you’re running on a VPS where a local container is simpler and cheaper, those are valid reasons to stick with what you have.
The branching workflow has been worth it for projects where I need to test migrations safely or give preview environments real data.