Neon vs PlanetScale in 2026: Serverless or Always-On Postgres
Neon vs PlanetScale in 2026 is a choice between two designs of managed Postgres. Neon separates storage from compute so compute can autoscale and scale to zero, and branches are cheap; it has a free plan and bills per CU-hour. PlanetScale runs always-on clusters with a primary and two replicas across availability zones, offers local-NVMe Metal machines and sharding, and has no free plan, with Postgres from $5 a month. Neon suits variable and development-heavy workloads; PlanetScale suits steady production load where availability and performance come first.
Facts are from neon.com/pricing, planetscale.com/pricing and each vendor's docs, as of November 2026. PlanetScale prices are for AWS us-east-1.
#Architecture in one paragraph each
Neon stores data in a separate storage layer and runs Postgres compute on demand. A compute can autoscale (up to 16 CU on Launch, where 2 CU is about 8 GB of RAM) and suspend when idle, after 5 minutes on Free. A branch is a new compute over a copy of the data at a point in time, which is why branches are fast and cheap.
PlanetScale runs Postgres as a cluster: one primary handling writes and two replicas in separate availability zones receiving changes through streaming replication, promotable on failover. Storage is either network-attached (up to 64 TB, with configurable IOPS) or local NVMe on Metal. Connections go through PgBouncer on port 6432 or directly on 5432. For MySQL workloads it also runs Vitess, and Neki brings horizontal sharding to Postgres.
#Pricing
| Neon | PlanetScale | |
|---|---|---|
| Free | Yes: 100 CU-hours and 1 GB per project, 100 projects | No (Hobby retired April 8, 2024) |
| Smallest paid | Launch, pay per use, no minimum | Postgres PS-5 single node $5/mo (1/16 vCPU, 512 MiB) |
| Smallest HA | Not a separate SKU; storage is multi-AZ on all plans | PS-5 HA (1 primary + 2 replicas) $15/mo |
| Compute rate | $0.106/CU-hour (Launch), $0.222 (Scale) | Fixed per SKU, up to PS-2560 (32 vCPU, 256 GiB) |
| Storage | $0.35/GB-month | Included volume per SKU; extra varies by region and cloud |
| NVMe | No | Metal, from $50/mo (M-10 HA) |
| Dev branches | 10 per project on Free/Launch, 25 on Scale, $1.50/branch-month extra | Postgres: $5 per dev branch per month |
What the models mean in practice:
- A staging database used two hours a day costs almost nothing on Neon. On PlanetScale it is a $5 single node running all month.
- A production API under steady load on Neon at 1 CU for 730 hours is about $77 of compute on Launch. On PlanetScale a fixed SKU with HA is a known monthly price; compare the SKU that matches your CPU and memory needs.
#Feature comparison
| Neon | PlanetScale | |
|---|---|---|
| Scale to zero | Yes | No |
| Autoscaling | Yes | Resize by changing SKU |
| High availability | Multi-AZ storage; uptime SLA on Scale | Primary + 2 replicas across AZs on production clusters |
| Read replicas | All plans | Replicas in every HA cluster |
| Pooling | PgBouncer, up to 10,000 pooled connections per compute | PgBouncer |
| Restore | Instant restore up to 7 d (Launch) or 30 d (Scale) | Automatic backups every 12 hours |
| Sharding | No | Neki (Postgres), Vitess (MySQL) |
| Clouds | AWS (Azure regions deprecated) | AWS, GCP, Azure |
| Extras | Auth, Data API, Object Storage, Functions, Realtime beta | Query insights, Traffic Control (Postgres) |
| MySQL | No | Yes, via Vitess |
#Branching compared
Neon's branches are the core of its developer experience. You branch from production at a point in time, get a full copy of the data, run tests or a preview deploy against it, and delete it. Free and Launch include 10 branches per project.
PlanetScale's strongest branching story is on Vitess: development branches plus deploy requests that apply non-blocking schema changes to production, with revert. For Postgres, PlanetScale branches are isolated environments created from production backups; development branches are single-instance databases at $5 a month each, promoted to the HA architecture when needed.
If "a database per pull request" is your main requirement, Neon is the better fit. If "safe online schema changes on a large MySQL database" is, PlanetScale Vitess is.
#Connecting from serverless code
Neon has an HTTP and WebSocket driver for edge runtimes:
import { neon } from '@neondatabase/serverless'
const sql = neon(process.env.DATABASE_URL!)
const [user] = await sql`select id, email from users where id = ${userId}`PlanetScale Postgres is a regular Postgres endpoint: use any driver over TLS, through PgBouncer for many short-lived connections:
# PgBouncer
DATABASE_URL="postgresql://<user>:<password>@<host>:6432/<db>?sslmode=require"
# Direct, for migrations
DIRECT_URL="postgresql://<user>:<password>@<host>:5432/<db>?sslmode=require"#Who should pick which
Pick Neon if:
- you want a free tier, or many small databases,
- traffic is spiky or idle much of the time,
- you rely on branches with real data for CI and previews,
- you want auth and object storage from the same vendor.
Pick PlanetScale if:
- you need HA across availability zones from day one,
- you want local NVMe performance,
- you need GCP or Azure,
- you run MySQL with Vitess, or need sharding.
#If you need a backend, not only a database
Both are database services. If you also need auth, file storage, realtime and an API, a backend platform may save work. StitchDB is one option: a dedicated Postgres per project with Auth, REST and GraphQL, Realtime, Storage and Edge Functions, point-in-time recovery on every plan and flat pricing from $0 to $329 a month. Its limits: EU-only regions, no HA plan feature, and branches built from migrations. See StitchDB vs Neon and StitchDB vs PlanetScale, or what's included.
#Moving between them
Both are standard Postgres (for PlanetScale's Postgres product), so a move is a normal Postgres migration:
- Check extensions on the source with
select extname from pg_extension;and confirm the target supports them. - Use direct connections, not poolers, for the dump or replication: on Neon, the hostname without
-pooler; on PlanetScale, port 5432 rather than PgBouncer on 6432. - For small databases,
pg_dump -Fcandpg_restore --no-ownerduring a short write pause. - For larger ones, logical replication from the source to the target, then a brief write pause while the last changes arrive and you point the app at the new URL.
- Reset sequences if your tool doesn't copy them, and compare row counts on the busiest tables before deleting the old database.
Moving from PlanetScale Vitess (MySQL) to Neon is a different project: types, quoting and some SQL change. Tools like pgloader help with the data, but plan time for queries.
If you are considering a full backend instead, StitchDB's Import from Postgres runs these steps for you, with a live copy when the source allows logical replication and a serverless driver for edge code afterwards.
#FAQ
#Is Neon or PlanetScale cheaper?
For idle and development databases, Neon, often free. For a small always-on production database, PlanetScale's $5 single node or $15 HA PS-5 is a low, fixed price. Under steady heavy load, compare a PlanetScale SKU to Neon's CU-hours for your actual usage.
#Does PlanetScale still offer a free tier?
No. The Hobby plan was retired on April 8, 2024.
#Can Neon do high availability?
Neon stores data across availability zones on all plans and offers an uptime SLA on Scale. It doesn't use PlanetScale's model of a primary with two standby replicas.
#Which is better for MySQL?
PlanetScale, through Vitess. Neon is Postgres only. Moving from MySQL to Postgres is covered in Migrate from PlanetScale (MySQL) to Postgres.
#Do Neon and PlanetScale support pgvector?
Neon lists pgvector and PostGIS among the extensions on all plans. PlanetScale Postgres offers a curated set of tested extensions that you manage from the dashboard or CLI; check its extension list for the exact ones you need before choosing.
Need Postgres plus the backend around it? Try StitchDB free.