Neon Serverless PostgreSQL
Term 65 of 68 in the ERPStack technical glossary
What is Neon Serverless PostgreSQL?
Neon is a serverless PostgreSQL platform that separates storage from compute, enabling instant database branching, autoscaling to zero during idle periods, and scale-on-demand without manual instance sizing.
Neon Serverless PostgreSQL at a glance
- What it is
- PostgreSQL with storage and compute separated, so compute can scale to 0 when idle
- Branching
- A copy-on-write database branch per pull request, created in seconds rather than restored from a dump
- Compatibility
- Ordinary PostgreSQL wire protocol on port 5432 — Drizzle ORM 0.45 needs 0 code changes
- Watch for
- Cold starts after idle, and connection pooling being mandatory rather than optional
- Built with
- Neon Serverless PostgreSQL on port 5432, Drizzle ORM 0.45 unchanged, branches created by GitHub Actions, Next.js 16 preview deployments on Vercel, Playwright 1.59 run against each branch
- Numbers that matter
- Compute scales to 0 when idle; 1 branch per pull request; port 5432 unchanged; 2 things to plan for, cold starts and pooling
- Compare with
- Self-managed Postgres on AWS or Microsoft Azure, and MongoDB Atlas as a managed alternative
- Commonly paired with
- Drizzle ORM, Vercel deployments, GitHub Actions and Playwright preview tests
- Version horizon
- Upstream PostgreSQL supports majors 14 through 18; PostgreSQL 18 reaches end of life on 14 November 2030. A branch workflow inherits that date.
- Connection discipline
- A pooler in front, TypeScript 5.9 holding 1 connection per request, and Sentry alerting on pool exhaustion rather than on the port 5432 timeout it produces.
- Where it fits
- SaaS and Multi-tenant Architecture products on Vercel or AWS, where a Next.js 16 preview deployment needs its own database for the life of 1 pull request.
How Neon Serverless PostgreSQL works in production
The ERPStack approach to Neon Serverless PostgreSQL
We use Neon serverless PostgreSQL for all staging environments and CI pipeline database branches, reducing infrastructure costs by 80% vs. always-on RDS instances while maintaining production parity.
Frequently asked questions about Neon Serverless PostgreSQL
What does Serverless PostgreSQL change architecturally?
It separates storage from compute. In Serverless PostgreSQL the data lives in a storage layer while the compute node that serves queries can be suspended when idle and resumed on demand. That makes non-production environments almost free to keep around, and it is why a preview environment per pull request becomes practical rather than a budget conversation.
How does database branching help a team?
It makes environments disposable. Serverless PostgreSQL branching creates a copy-on-write clone of production-shaped data in seconds, so a migration can be tested against realistic data and then thrown away. Compared with restoring a dump into a staging database — which takes long enough that people skip it — this changes what teams actually verify before a schema change reaches production.
What are the trade-offs of a serverless database?
Cold starts and connection handling. Serverless PostgreSQL compute that has scaled to 0 needs to resume before answering, which adds latency to the first request after an idle period. Serverless application functions also open connections aggressively, so pooling stops being optional. Both are manageable with a pooled endpoint and a warm production instance, but neither should be discovered in production.
Is it still just Postgres?
Yes at the protocol level, which is the point. Serverless PostgreSQL speaks the standard wire protocol on port 5432, so Drizzle ORM 0.45, existing SQL, migration tooling and admin clients work unchanged, and moving to a conventional managed instance later is a connection-string change. That portability is what makes the choice low-risk compared with a proprietary database with its own dialect.