Neon

What it does

Neon is a serverless Postgres database. It runs standard, open-source PostgreSQL but separates compute from storage, which makes two things possible that a normal Postgres box can't do: compute that scales to zero when idle, and instant, copy-on-write branching of an entire database.

Concretely, the parts you actually interact with:

• Scale-to-zero compute. An idle database suspends its compute and bills nothing for it while suspended. When a query arrives, it wakes back up.
• Branching. A branch is a full copy of your data and schema at a point in time, created in roughly a second without physically duplicating the bytes. You write to a branch without affecting the parent.
• Point-in-time restore. Because storage keeps a history of changes, you can create a branch (or restore) from an earlier moment, which is useful after a bad migration or a wrong DELETE.
• Connection pooling and a serverless driver. Neon ships a pooled connection endpoint plus an HTTP/WebSocket driver, so you can reach Postgres from serverless and edge runtimes that don't hold long-lived TCP connections well.

It speaks real Postgres over the wire. Your existing client libraries, ORMs, and pg_dump/psql tooling connect to it the same way they connect to any other Postgres instance.

Who it's best for

Neon fits teams building modern web apps on serverless or platform hosts (Vercel, Netlify, Cloudflare, Fly) who want Postgres without running and tuning a server. The branching model is the standout fit for two workflows:

• Preview environments. Wire branch creation into CI so every pull request gets its own isolated database seeded from production's schema (and optionally a data snapshot). Reviewers test against real data shapes; the branch is deleted on merge.
• Migration testing. Branch production, run the migration on the branch, inspect the result, throw the branch away. This turns "will this migration lock the table" into a cheap experiment.

It's also a sensible default for side projects and internal tools that sit idle most of the day — you pay for storage and the occasional wake-up rather than a server running 24/7.

Where it's strong

Scale-to-zero economics. For spiky or low-traffic workloads, paying nothing for idle compute is a real cost difference versus an always-on instance. A dozen rarely-touched preview databases cost far less here than a dozen provisioned instances.

Branching as a first-class primitive. Plenty of databases let you take a snapshot; few let you fork the live database in a second and write to the fork. This is the feature people adopt Neon for and the one that's genuinely hard to replicate elsewhere.

Postgres compatibility, not a lookalike. There's no proprietary query dialect to learn and no driver lock-in at the protocol level. Prisma, Drizzle, Knex, SQLAlchemy, and raw psql all work unchanged. If you outgrow Neon, your SQL and schema move to any Postgres host.

pgvector support. The pgvector extension is available, so you can store and query embeddings in the same database as your relational data instead of bolting on a separate vector store for smaller AI projects.

Where it's weak

Cold starts. The first query after the compute has suspended pays a wake-up penalty — typically on the order of a second or two. For most apps that's invisible; for latency-sensitive paths, or a public endpoint that must always answer instantly, it's a real consideration. You can keep compute warm, but doing so gives up the scale-to-zero saving that drew you in.

Database only. Neon is Postgres and nothing else. There's no bundled authentication, file/object storage, autogenerated REST/GraphQL API, or edge-function runtime. That's a clean separation of concerns, but it means more wiring than an all-in-one backend platform.

Connection model takes care. Serverless functions can open many short-lived connections fast, and Postgres has connection limits. You generally must route through Neon's pooled endpoint or the serverless driver. Point an unpooled, high-concurrency function fleet at the direct endpoint and you'll exhaust connections — a predictable failure that catches people who treat it like a single long-running server.

Compute ceilings and write scaling. This is a single-primary Postgres, not a distributed/multi-region write system. Very high sustained write throughput or strict multi-region low-latency writes are outside its sweet spot; that's a job for a different class of database.

Pricing context

Neon has a usable free tier for evaluation and small projects, with paid plans starting at $19/month. Billing is usage-based on top of the plan — driven by compute hours, storage, and data transfer — so an idle project stays cheap while a busy one scales with consumption. The practical implication: estimate cost from your active compute time and data size, not from a flat per-server price. As always with usage-based billing, a misconfigured always-on setting or a runaway query loop can move the bill more than the plan tier does. (Exact figures are re-verified against the vendor's pricing page weekly; treat the $19 starting point as the current floor.)

Verdict

Neon is the right pick when you want genuine Postgres with serverless economics and database branching, and you're comfortable assembling the rest of your stack (auth, storage, APIs) yourself. The branching workflow alone justifies it for teams that lean on preview environments or do frequent migrations.

Skip it if you want an all-in-one backend — Supabase bundles Postgres with auth, storage, edge functions, and an autogenerated API, and is the better starting point when you'd rather not wire those together. If you've standardized on a single cloud, the managed Postgres from that provider (RDS/Aurora, Cloud SQL) may integrate more tightly with the rest of your infrastructure, at the cost of branching and scale-to-zero. And if your real problem is multi-region writes or massive write throughput, look at a distributed SQL system instead.

For most serverless web apps — especially anything deployed on Vercel with per-PR previews — Neon's model fits cleanly, and the free tier is enough to test branching and cold-start behavior against your own workload before committing.