Neon
Neon is a managed Postgres platform with two standout ideas: serverless compute (it separates compute from storage so compute can autoscale and even hibernate) and instant database branching (a full copy-on-write branch of your data in seconds). Underneath, it's still plain Postgres.
Branching is the headline feature: spin up an isolated database per pull request or experiment, run migrations against it, and throw it away — no more everyone fighting over one shared dev database.
TL;DR
- It's real Postgres — design schemas, indexes, and queries as usual.
- Branching gives every PR/preview its own isolated database.
- Compute/storage separation enables autoscaling and scale-to-zero.
- Mind connection management — use pooling from serverless runtimes.
Quick Example
A pooled connection — the standard, safe way to talk to Neon from an app:
Core Concepts
- Serverless Postgres — compute autoscales with load and can hibernate when idle (scale-to-zero).
- Compute/storage separation — storage is durable and independent of the compute that serves it.
- Branching — copy-on-write branches of your database for environments and experiments.
- Pooling — a built-in pooler endpoint for high connection counts.
Branching Workflow
Branching shines when your pipeline creates preview environments:
This removes shared-dev-database conflicts and makes previews realistic — each one has its own data.
Best Practices
- Use migrations for all schema changes (the branch is still Postgres).
- Use least-privilege database roles.
- Use the pooled connection endpoint from serverless functions to avoid exhausting connections.
- Plan and test backups/restores — branches aren't a backup strategy.
Comparison
See PlanetScale and Supabase.
Common Mistakes
Exhausting connections from serverless
Branch sprawl
FAQ
Is Neon just Postgres?
Yes — your app connects to standard Postgres and you get SQL, indexes, constraints, and most extensions. Neon adds serverless scaling and branching on top, but you design and query the database exactly as you would any Postgres.
What is database branching and why is it useful?
A branch is a near-instant, isolated copy of your database (copy-on-write, so it's cheap). It's ideal for giving each pull request or preview deploy its own database to run migrations and tests against, without touching production or a shared dev DB.
How does serverless Postgres handle connections?
Serverless runtimes can open many short-lived connections, which overwhelms Postgres. Neon provides a pooled connection endpoint (and you can add your own pooler) so a large number of clients share a small pool of backend connections.
Neon or Supabase?
Both are serverless Postgres. Choose Neon when you mainly want a scalable Postgres with branching. Choose Supabase when you also want batteries-included auth, storage, realtime, and instant APIs around the database.
Related Topics
- PostgreSQL — The underlying database
- Supabase — Postgres BaaS alternative
- PlanetScale — Branching for MySQL
- Database Migrations — Schema changes per branch
- Serverless Patterns — Where Neon fits