Neon vs PlanetScale: Serverless vs Provisioned (2026)

Quick verdict

Short answer

Choose Neon if you want PostgreSQL that scales down to zero when idle, branches that include your data for every preview environment, and a free plan to start. Choose PlanetScale if you need MySQL with Vitess sharding and non-blocking schema changes, or want an always-on, provisioned PostgreSQL cluster with replicas across availability zones (or local NVMe storage with Metal), and you are happy to pay from day one: PlanetScale has no free plan. If you are choosing between the engines themselves, read MySQL vs PostgreSQL first.

How we know: This comparison is research-based: products, engines, branching, schema-change workflows, regions, ownership and plans were checked against Neon's and PlanetScale's official documentation and pricing pages in October 2026. We have not run performance tests, so no speed, latency or cold-start claims are made.

Neon is a managed PostgreSQL service whose open source storage engine (Apache-2.0) separates storage from compute, enabling autoscaling, branching and scale to zero. Databricks announced an agreement to acquire Neon in May 2025, and Neon's documentation now states that Neon joined Databricks in 2025; Neon calls its database Lakebase Postgres and also sells Auth, a Data API, Functions, Object Storage and an AI Gateway alongside it. It supports Postgres 14 to 18.

PlanetScale is a managed database company that, as of October 2026, sells three products. Vitess is its original MySQL-compatible service, running MySQL 8 on the Vitess sharding system. Postgres is a fully managed PostgreSQL service supporting versions 17 and 18, as high-availability clusters (a primary plus two replicas) or single-node databases. Neki is horizontal sharding for Postgres, which PlanetScale's documentation labels Platform Preview (beta). PlanetScale does not offer a free plan: its plans documentation states that the former Developer or Hobby plan is gone and that all databases require a paid subscription, starting with the Base plan (formerly Scaler Pro).

So this is not a like-for-like pairing: Neon is one engine on an elastic, usage-billed model; PlanetScale offers two engines on a provisioned, cluster-size model. For the backend-platform angle, see Supabase vs Neon and Supabase vs PlanetScale.

Side by side

Aspect	Neon	PlanetScale
Engines	PostgreSQL only (14 to 18)	MySQL 8 on Vitess; PostgreSQL 17 and 18; Neki sharded Postgres in preview
Free plan	Yes, Free plan with per-project compute and storage limits	No; all databases need a paid subscription
Billing basis	Usage: CU-hours of compute and GB-months of storage	Provisioned cluster size per month, plus storage, backups and egress
Idle behaviour	Scale to zero after inactivity; autoscaling between limits	Always-on clusters at a fixed size you choose
High availability	Compute separated from replicated storage; read replicas available	HA clusters with a primary and two replicas across availability zones; single-node Postgres optional
Branching	Copy-on-write branches with schema and data, from any point in the history window	Vitess: schema branches with deploy requests. Postgres: isolated, empty branches or branches restored from a backup
Schema changes	Standard Postgres DDL on each branch	Vitess: non-blocking schema changes via deploy requests. Postgres: DDL applied manually per branch
Horizontal sharding	Not offered	Vitess (MySQL) and Neki (Postgres, preview)
Clouds and regions	Eight AWS regions; Azure regions deprecated	AWS (12 regions) and Google Cloud (7 regions)
Main trade-off	Elastic and cheap to start, but Postgres only and owned by Databricks	Provisioned clusters and sharding, but no free plan and Vitess has MySQL compatibility limits

Key differences

Elastic serverless versus provisioned clusters

Neon measures compute in compute units (about 4 GB of RAM each, with CPU and local SSD), autoscales between limits (up to 2 CU on Free and 16 CU on Launch and Scale, with fixed sizes up to 56 CU on Scale) and suspends compute after 5 minutes of inactivity by default. You pay per CU-hour actually used. Its separated architecture brings some documented differences from stock Postgres, such as no tablespaces and a neon_superuser role in place of a full superuser.

PlanetScale sells clusters of a chosen size that run continuously. Its Postgres HA clusters and Vitess clusters include a primary and two replicas; single-node Postgres drops the replicas for lower cost and is intended, in PlanetScale's words, for "development or production workloads that do not require high availability". PlanetScale Metal places databases on locally attached NVMe drives instead of network-attached storage. You choose and pay for capacity up front, which in our view suits steady production traffic more than spiky or idle workloads.

Branching and schema changes

Neon branches are copy-on-write clones that include schema and data from the moment (or past point) you branch, without adding load to the parent. That makes a branch per pull request with real data straightforward; you then apply migrations with normal Postgres DDL.

On PlanetScale Vitess, branching is about schema: you change a development branch and open a deploy request, and PlanetScale applies the change to production as a non-blocking schema change, with safe migrations that support schema reverts. On PlanetScale Postgres, the documentation states that branches are completely isolated databases with no data replication between them; a new branch starts empty unless you create it from a backup, there are no deploy requests, and there is currently no automated way to merge schema changes between branches. Development branches are billed only for the time they run.

MySQL on Vitess: what you give up

If you pick PlanetScale for MySQL, read its compatibility page first. It states that PlanetScale does not support any form of stored routines (procedures, functions, triggers or events), that LOAD DATA INFILE is not supported, that every table needs a unique, non-null key, and that only InnoDB is supported. Recursive CTEs have only experimental support for SELECT. Foreign key constraints are supported only in unsharded databases and must be enabled per database. These limits do not apply to PlanetScale's Postgres product or to Neon.

Scaling out

Neon scales a single Postgres database up (autoscaling) and out for reads (read replicas), but does not shard writes across nodes. PlanetScale's Vitess product shards MySQL horizontally, and Neki extends that idea to Postgres. Because Neki is in Platform Preview, which PlanetScale's terms treat as beta, we would not plan a production system around it without reading its current limitations. If sharding is not on your roadmap, this difference matters less than billing and branching.

Ownership and lock-in

Neon is part of Databricks and shares its architecture with Databricks Lakebase. PlanetScale is an independent company; its Enterprise plan also offers single-tenant deployments and PlanetScale Managed, which runs in the customer's own AWS or GCP account. Both services run standard engines, so pg_dump (Neon, PlanetScale Postgres) or MySQL dump tools (PlanetScale Vitess) remain exit routes. PlanetScale Postgres major-version upgrades from 17 to 18 are done by creating a new database and migrating online rather than in place.

Pricing and licensing

Neon. Listed on the Neon pricing page and plans documentation in October 2026, in USD. Free: 0 USD per month, up to 100 projects, 100 CU-hours per project per month, 1 GB storage per project (20 GB per account), 10 branches per project, scale to zero after 5 minutes. Launch: usage-based at 0.106 USD per CU-hour. Scale: usage-based at 0.222 USD per CU-hour. On paid plans, storage is 0.35 USD per GB-month, extra branches are 1.50 USD per branch-month, and public network transfer includes 500 GB per project, then 0.10 USD per GB. Neon states there is no monthly minimum.

PlanetScale. Listed on the PlanetScale pricing page in October 2026, in USD per month, for AWS us-east-1; prices vary by region and cluster size. There is no free plan. Postgres: single-node from 5 USD (PS-5), HA three-node clusters from 15 USD (PS-5), Metal clusters from 50 USD (M-10); billed as cluster size plus storage, backups and egress, with optional dedicated PgBouncer and extra replicas. Vitess: from 39 USD (PS-10, one primary plus two replicas), billed as cluster size plus storage and optional VTGates and sharding configuration. Neki: listed from 30 USD (PS-10 Arm), billed as shard compute plus routers, storage, backups and network usage, while in Platform Preview. Development branches start at 5 USD per month and are billed only while they exist. Enterprise pricing is by contact. The storage, backup and egress rates were not shown as fixed figures on the page we read, so check them in PlanetScale's pricing tool for your region.

The models differ in kind: Neon bills for compute that is actually running, so an idle database costs mainly storage; PlanetScale bills for the cluster you provision whether it is busy or not.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Neon strengths

Free plan with up to 100 projects, suitable for prototypes and many small databases
Scale to zero and autoscaling, billed per CU-hour with no monthly minimum
Copy-on-write branches include data and can be created from a past point in time
Supports a wide range of Postgres versions (14 to 18)

PlanetScale strengths

Offers both MySQL (Vitess) and PostgreSQL under one vendor
HA clusters with a primary and two replicas across availability zones as standard
Vitess deploy requests give non-blocking schema changes with reverts
Horizontal sharding for MySQL today, with sharded Postgres (Neki) in preview
Runs on AWS and Google Cloud, with Metal (local NVMe) and bring-your-own-cloud options

Limitations

Neon limitations

PostgreSQL only, and no horizontal write sharding
Owned by Databricks; long-term direction tied to Lakebase
Azure regions deprecated; new projects are AWS only
Architecture-driven differences from stock Postgres (no tablespaces, no full superuser)

PlanetScale limitations

No free plan; every database requires a paid subscription
Vitess does not support stored procedures, functions, triggers or events
Foreign keys on Vitess work only in unsharded databases
Postgres branches start empty (or from a backup) and schema changes are not merged between branches automatically
Neki is in Platform Preview (beta)

When to choose each

Choose Neon if

You want PostgreSQL that costs little or nothing when idle
You need a branch with production-like data for every pull request or preview deploy
You run many small databases, for example per tenant, per developer or per agent
You want to start on a free plan

Choose PlanetScale if

You need MySQL with horizontal sharding and non-blocking schema migrations
You want a provisioned, always-on Postgres cluster with replicas across availability zones
You need Google Cloud regions or deployment into your own AWS or GCP account
You prefer paying for a fixed cluster size rather than metered compute

When neither is right

You need a full backend (auth, storage, realtime, functions) rather than a database: see Supabase vs Neon and Supabase vs Firebase.
You rely on MySQL stored procedures or triggers: a managed MySQL service without Vitess restrictions fits better; compare engines in MySQL vs PostgreSQL.
You need a document database: see MongoDB vs PostgreSQL.
For other Postgres platforms, see Supabase alternatives.

Final recommendation

Bottom line

For PostgreSQL projects that start small, change often or sit idle, Neon is the better fit in our view: a free plan, branches with data and billing only for active compute. PlanetScale is the choice when you want provisioned, highly available clusters from the start, need MySQL with Vitess sharding and deploy requests, or need Google Cloud; budget for a paid plan from day one and check the Vitess compatibility limits before migrating an existing MySQL application.

Frequently asked questions

Does PlanetScale have a free tier?

No. PlanetScale's plans documentation states that it does not offer a free plan (previously the Developer or Hobby plan) and that all databases require a paid subscription. The cheapest listed option in October 2026 was a single-node Postgres database; see the pricing section above.

Does PlanetScale support PostgreSQL?

Yes. PlanetScale sells a managed Postgres product supporting PostgreSQL 17 and 18, as HA clusters or single-node databases, and Neki, a sharded Postgres product in Platform Preview. Its original product, Vitess, is MySQL-compatible.

Is Neon still independent?

No. Databricks announced an agreement to acquire Neon in May 2025, and Neon's documentation now states that Neon joined Databricks in 2025. Neon continues to be sold as its own service.

Which has better branching?

They do different things. Neon branches are copy-on-write clones with schema and data. PlanetScale Vitess branches support schema changes merged through deploy requests; PlanetScale Postgres branches are isolated databases that start empty or from a backup, with no automated schema merging.

Can I use stored procedures on PlanetScale?

Not on PlanetScale Vitess: its MySQL compatibility page states that it does not support any form of stored routines. PlanetScale Postgres is described as fully PostgreSQL compatible.

Sources

Checked October 2026.

How we research comparisons: our editorial method.