· neon / planetscale / postgres
Neon vs PlanetScale — serverless Postgres vs serverless MySQL
Neon has the free tier, the better dev branching, and the Postgres ecosystem. PlanetScale has no cold starts, NVMe speed, and enterprise schema governance. They stopped competing in April 2024 when PlanetScale killed its free tier.
By Ethan
2,252 words · 12 min read
If you’re a solo developer or an early-stage team, pick Neon. You get 0.5 GB and 100 compute-unit-hours free, real Postgres, and instant data branches that plug into Vercel preview deployments. PlanetScale dropped its free tier in April 2024. The entry point is now $5/month — which is fine if you’re paying, but it means the two products aren’t really competing for the same audience anymore.
Who this is for
Developers choosing between a serverless Postgres database and a serverless MySQL (or now Postgres) database for a new project. If you’re migrating an existing MySQL application at scale, this article will help you think through PlanetScale’s strengths — but the free-tier comparison won’t matter to you.
What we compared
Neon — serverless Postgres with separated compute and storage. Tested against the current free tier and Launch plan as of June 2026. Architecture: Safekeepers (WAL consensus), Pageserver (on-demand page reconstruction from object storage), stateless compute. Open source (AGPLv3/Apache 2.0).
PlanetScale — originally a MySQL-on-Vitess platform, now also offering Postgres (GA September 22, 2025). Tested against current pricing and docs as of June 2026. Architecture: always-on dedicated infrastructure with locally-attached NVMe SSDs, proprietary Postgres operator, PgBouncer proxy.
This is a documentation and pricing comparison, not a benchmark. Where numbers appear, we note the source.
Quick verdict
| Neon | PlanetScale | |
|---|---|---|
| Free tier | ✅ 0.5 GB / 100 CU-hours/month | ❌ None (removed April 2024) |
| Branching | Full data clone (copy-on-write, instant) | Schema-only by default; Deploy Request workflow |
| Cold start | 300–800 ms (scale-to-zero default) | None — always-on |
Neon
Architecture
Neon separates compute from storage entirely. When your Postgres compute scales to zero after five minutes of inactivity, your data doesn’t go anywhere — it lives in object storage (S3-compatible), reconstructed on demand by the Pageserver component.
The write path goes through Safekeepers: a cluster of nodes that uses Paxos consensus to commit WAL before the transaction returns. This replaces fsync on a single disk with a network quorum. The Pageserver replays that WAL to reconstruct any page at any point in time, which is what makes branching instant — creating a branch is a metadata operation, not a copy operation.
Pricing
| Plan | Compute | Storage | Branches |
|---|---|---|---|
| Free | 100 CU-hours/month (auto-scales to 2 CU) | 0.5 GB | 10 |
| Launch | $0.106/CU-hour (up to 16 CU) | $0.35/GB-month | 10 included |
| Scale | $0.222/CU-hour (up to 56 CU, 224 GB RAM) | $0.35/GB-month | 25 included |
A few things to understand about compute-unit pricing: a 0.25 CU compute is the minimum (0.25 vCPU, 1 GB RAM). If your app is idle most of the month and scales to zero, your bill reflects only the active hours. The free plan suspends your compute if any limit is hit — and it doesn’t resume until the next billing month.
Branches are billed differently from root databases: child branches use copy-on-write deltas from the parent, so a branch that hasn’t diverged much costs almost nothing. Extra branches beyond plan limits cost $1.50/branch-month.
Read replicas are billed as separate compute instances.
Branching
Neon’s branching is its clearest differentiator. Because every branch is a point-in-time clone of the WAL history, you get a full copy of your production data in a dev branch — instantly, without physically copying data. You can:
- Create a branch for each pull request and automatically delete it when the PR closes
- Point-in-time restore by branching from any moment in your history window (6 hours on Free, 7 days on Launch, 30 days on Scale)
- Run destructive schema migrations against a data-bearing branch before touching production
The Vercel integration uses this: each preview deployment gets its own Neon branch with production data. When the PR merges, the branch is deleted. That loop works out of the box.
Cold starts
Scale-to-zero is on by default. After five minutes of inactivity, compute suspends. The next query wakes it up, and that wake-up takes 300–800 ms by community measurement (Neon’s official docs say “a few hundred milliseconds”).
You can mitigate this:
- Paid plans can disable scale-to-zero entirely (compute only suspends after 7 days of inactivity — effectively always-on)
sslnegotiation=directin the connection string saves ~119 ms per Neon’s own measurement- PgBouncer in transaction mode (Neon’s built-in pooler) keeps connections warm after the initial wake-up
For most serverless applications, the first request after an idle period pays the cold-start penalty, and subsequent requests don’t. Whether that’s acceptable depends entirely on your traffic pattern.
Connection pooling
Neon ships a built-in PgBouncer in transaction mode, accessible via a separate pooled connection string. It supports up to 10,000 concurrent client connections regardless of your Postgres max_connections (which ranges from 104 on 0.25 CU to 4,000 on large instances).
Transaction mode has known limitations: LISTEN/NOTIFY, temp tables, and SQL-level prepared statements don’t work through the pooler. Use the direct connection string for migrations, pg_dump, and long-running analytics.
Neon also ships a serverless HTTP driver for edge runtimes (Cloudflare Workers, Vercel Edge Functions) that doesn’t require WebSocket support.
PlanetScale
Architecture
PlanetScale runs on always-on dedicated infrastructure with locally-attached NVMe SSDs. There is no scale-to-zero. A production branch is 1 primary plus 2 replicas across three availability zones, with automatic failover.
PlanetScale originated as a managed Vitess (MySQL) platform — Vitess is the horizontal sharding layer that powers GitHub, Slack, and YouTube’s MySQL at scale. That battle-tested lineage gives PlanetScale its confidence at high connection counts and large data volumes.
The Postgres product (announced July 2025, GA September 22, 2025) runs a proprietary Postgres operator with PgBouncer. PlanetScale is building a sharding engine called Neki for Postgres from first principles (not a Vitess fork). At time of writing, Neki is in development and Postgres plans run on a single-node or unsharded model.
Pricing
| Plan | Price | Notes |
|---|---|---|
| Free tier | ❌ None | Removed April 8, 2024 |
| Postgres Single Node | $5/month | Network-attached storage |
| Postgres Metal | $50+/month | Local NVMe, higher throughput |
| Vitess PS-20 | ~$59/month | 2 vCPU |
| Vitess PS-40 | ~$99/month | 4 vCPU |
Storage is 10 GB included, then $0.50/GB. Egress is 100 GB included, then $0.06/GB. Connections are unmetered.
The free tier removal deserves its own paragraph. On March 6, 2024, PlanetScale stopped accepting new Hobby database creation. On April 8, 2024, it deleted existing Hobby databases and required migration to paid plans. The cheapest paid tier at the time was $39/month (Scaler Pro). For developers running side projects on $0, this meant a jump from $0 to $39/month. The company cited profitability priorities and parted ways with members of their team (primarily Sales and Marketing). The developer migration to Neon, Turso, and Supabase that followed was immediate and large.
Branching
PlanetScale’s branching is a governance tool, not a data-clone tool.
MySQL (Vitess) — mature, well-documented:
Development branches are schema-only by default. There is no production data in a dev branch unless you use Data Branching® (restore from backup — additional cost and friction). The workflow is:
- Create a dev branch from production
- Make DDL changes on the dev branch
- Open a Deploy Request — PlanetScale diffs the schemas and shows what’s being added or removed
- Peer-review the diff, validate in staging
- Add to the deploy queue — PlanetScale runs the migration non-blocking on production using online DDL (gh-ost internally)
This model enforces discipline: you can’t DDL directly on a protected production branch. All schema changes go through a peer-reviewed queue. For teams that have been burned by a direct ALTER TABLE on production, this is genuinely valuable.
Postgres (newer):
The Deploy Request workflow is in development for Postgres. Less documentation and less maturity than the MySQL branching system. No equivalent to Neon’s instant full-data copy-on-write clones.
Cold starts
None. PlanetScale runs always-on dedicated infrastructure. You pay whether the database is idle or handling 1M QPS. Latency is predictable because there’s no suspend/resume cycle.
Performance
PlanetScale published benchmarks in September 2025 comparing a PlanetScale M-320 (4 vCPU, 32 GB RAM, NVMe) against Neon Scale 8cu (8 vCPU, 32 GB RAM, network storage):
| Benchmark | PlanetScale | Neon | Delta |
|---|---|---|---|
| TPCC QPS (500 GB, 64 connections) | ~18,000 | ~12,500 | +44% |
| OLTP Read QPS (300 GB) | ~33,000 | ~27,000 | +22% |
| p99 latency | Lower | Higher variability | PlanetScale |
Caveat: these are self-published benchmarks by PlanetScale. The NVMe vs network storage gap is real — locally-attached SSDs consistently outperform network-attached storage at sustained throughput and p99 latency. But real-world workloads vary, and the workload design in any vendor benchmark favors the vendor. Independent third-party numbers would be more credible.
Head-to-head
Branching philosophy
This is the most fundamental design difference. Neon gives you production data in branches because branching is a WAL replay operation — the data comes for free. PlanetScale’s branching was built for schema governance, not environment replication; getting data into a branch requires additional steps and cost.
If you’re running preview deployments that need production-like data to catch real bugs, Neon wins without contest. If you’re managing a team that has had production incidents from unchecked DDL, PlanetScale’s Deploy Request workflow is what you want — and its non-blocking online DDL migrations are something you’d otherwise need to implement yourself with pt-online-schema-change or gh-ost.
Cold starts
PlanetScale has none. Neon has them by default and can eliminate them on paid plans by disabling scale-to-zero.
For always-on production traffic, disable scale-to-zero on Neon (Launch or Scale plan) and the cold start argument disappears. For free-tier projects, cold starts are unavoidable.
Connection pooling
Effectively a tie. Both ship built-in poolers in transaction mode. Both have HTTP-based serverless drivers for edge runtimes. Neon documents a 10,000 client connection limit via PgBouncer; PlanetScale lists connections as unmetered.
Free tier
Neon wins, unambiguously. There is no PlanetScale free tier. For anyone evaluating both products on a $0 budget, the comparison ends here.
Postgres ecosystem maturity
Neon IS Postgres — fully compatible, all extensions, any tool that works with standard Postgres works with Neon. It’s been in production since 2021.
PlanetScale Postgres has been GA since September 2025. It runs real Postgres 17, but in a managed environment where extension support is limited and the branching tooling is newer. For Postgres-native workflows, Neon is the safer choice today.
Use-case matrix
Choose Neon if:
- You need a free tier for prototyping, an open-source project, or a side project
- You’re on Vercel + Next.js and want per-PR preview databases with real data
- You need all Postgres extensions,
pg_dump, or any standard Postgres tool - Your workload is bursty or idle most of the time (PAYG billing that scales to $0)
- You prefer open-source infrastructure
Choose PlanetScale if:
- You have existing MySQL/Vitess infrastructure at scale and need horizontal sharding
- Schema change governance is a hard requirement (Deploy Request peer review + non-blocking DDL)
- You can’t accept any cold-start latency and don’t want to manage always-on configuration
- You’re running high-throughput MySQL workloads where NVMe throughput advantages compound
- You need PCI DSS or SOC 2 with dedicated single-tenant options
| Scenario | Pick |
|---|---|
| Next.js on Vercel | Neon |
| Side project / prototyping | Neon (free tier) |
| CI/CD preview databases with real data | Neon |
| Budget-constrained startup | Neon |
| Postgres-first, maximum compatibility | Neon |
| Enterprise MySQL app at scale | PlanetScale (Vitess) |
| Schema change governance team | PlanetScale |
| Latency-sensitive, no tolerance for cold starts | PlanetScale |
| High-throughput MySQL (1M+ QPS potential) | PlanetScale |
Verdict
Neon is the right default for most developers in 2026. The free tier is real (0.5 GB, 100 CU-hours), the Postgres compatibility is complete, and the branching model is genuinely useful for modern deployment workflows. If you’re starting a project and don’t have a specific reason to pay from day one, start on Neon.
PlanetScale is a legitimate choice if you need what it actually provides: non-blocking schema migrations with peer-reviewed Deploy Requests, always-on infrastructure without cold starts, and NVMe throughput at the high end. It left the developer/free-tier market in April 2024 by choice. That makes it a serious enterprise product — not a worse version of Neon.
Caveats
The PlanetScale Postgres product is ~9 months old (GA September 2025). Some limitations we’d flag for Neon today — extension support, branching maturity — may be resolved by the time you read this. Check the current docs.
The benchmark numbers in the performance section come from PlanetScale’s own benchmarks. Treat them as a floor on NVMe advantage, not a neutral measurement.
This article contains a referral link to Neon (the /go/neon link above). If you sign up and spend $20, toolchew earns $20 — see the disclosure at the top of this page.
References
- Neon pricing
- Neon architecture overview
- Neon branching
- Neon connection pooling
- Neon connection latency
- Neon Open Source Program
- PlanetScale pricing
- PlanetScale plans
- PlanetScale branching
- PlanetScale for Postgres announcement
- PlanetScale for Postgres GA
- PlanetScale vs Neon benchmarks
- PlanetScale free tier removal
- PlanetScale Hobby plan deprecation announcement