PlanetScale vs Neon
Both companies blew up their own comparison since I last wrote this. PlanetScale now sells Postgres. Neon got bought by Databricks and got cheaper. Here's what actually matters now.
Neon
Still Neon, and it's not close. PlanetScale has never brought back a free tier - everything starts paid from day one, even their new Postgres offering. Neon got acquired by Databricks in 2025 and came out the other side with a permanent free tier, storage prices cut 80%, and compute cut up to 25%. You're not choosing between MySQL and Postgres anymore - PlanetScale sells both now. You're choosing between "pay from database #1" and "backed by a company throwing AWS-scale discounts at you for free." That's not a hard call.
The Serverless Database Wars
Traditional databases don't scale to zero. You pay even when nobody's using your app. Serverless databases fix this - spin up on demand, scale down to nothing.
PlanetScale built its name on MySQL with Vitess, then launched PlanetScale for Postgres in private preview July 2025 and took it GA that September. Neon has been Postgres-only from day one, and in May 2025 Databricks agreed to acquire it for a reported ~$1B. So this is no longer "MySQL vendor vs Postgres vendor." It's two companies that both sell Postgres now, with very different pricing philosophies and very different owners.
Quick Comparison
| Factor | Neon | PlanetScale |
|---|---|---|
| Database | PostgreSQL | MySQL (Vitess) + Postgres (new, 2025) |
| Owner | Databricks (acquired May 2025) | Independent |
| Free Tier | Yes, permanent (100 CU-hrs, 0.5GB) | No (removed 2024, never returned) |
| Branching | Copy-on-write (instant) | Full copy (MySQL) / native (new Postgres) |
| Scale to Zero | Yes, on every plan | Yes (paid only) |
| Storage Price | $0.35/GB-mo (cut 80% post-acquisition) | Bundled per-plan (EBS-based on Postgres SKU) |
| Starting Price | Free / $0.106 per CU-hr (Launch) | $5/mo (new Postgres) / $39/mo (Vitess MySQL) |
| Foreign Keys | Yes (it's Postgres) | Yes on unsharded MySQL (GA 2024) / yes on new Postgres |
| ORM Support | All Postgres ORMs | MySQL ORMs + Drizzle, or Postgres ORMs on the new product |
The Free Tier Fiasco (Still Never Fixed)
In March 2024, PlanetScale killed their Hobby (free) plan. Overnight, thousands of side projects had 30 days to migrate or start paying. Two and a half years later, it still hasn't come back - and there's no sign it will. Every PlanetScale database, MySQL or the new Postgres product, starts billing on day one.
Neon went the opposite direction. In May 2025, Databricks agreed to acquire Neon for a reported ~$1B. Instead of squeezing the free tier post-acquisition (the usual playbook), Neon cut prices: storage dropped from $1.75/GB-month to $0.35/GB-month (an 80% cut), Launch-tier compute dropped from $0.14 to $0.106 per CU-hour, and the free tier's compute allowance doubled. The likely reason: Databricks' AWS spend gets them infrastructure at a steep discount, and they passed some of it down instead of pocketing all of it.
"PlanetScale had two and a half years to bring back a free tier and chose not to, even while launching a brand-new product. Neon got bought by a $100B company and got cheaper. Read that as a signal about who's optimizing for developers versus who's optimizing for margin."
PlanetScale Isn't MySQL-Only Anymore
The framing that made this comparison simple - "pick your database engine" - stopped being true in 2025. PlanetScale launched a Postgres product in private preview that July and took it generally available that September, running real Postgres 17 on their own proprietary operator (not Vitess - Vitess is MySQL-specific, and PlanetScale is building a separate sharding layer for Postgres called Neki).
PlanetScale's Postgres plans start at $5/month, undercutting their own MySQL/Vitess floor of $39/month by a wide margin. It ships with high availability, automatic failover, and connection pooling out of the box. So if you specifically wanted PlanetScale's operational polish but always hated being locked into Vitess's MySQL quirks, that option now exists.
What it doesn't ship with: a free tier. You're still paying from database #1, just less than before if you pick Postgres over MySQL. Meanwhile Neon's Postgres is free until you outgrow 100 CU-hours and 0.5GB - which covers most side projects and early-stage products indefinitely.
MySQL vs Postgres (Still Matters, Just Not the Whole Story)
If you're comparing PlanetScale's original Vitess/MySQL product to Neon, the engine differences still apply:
- Postgres advantages: Better JSON support, arrays, full-text search, more data types, larger ecosystem of extensions.
- MySQL/Vitess advantages: Battle-tested horizontal sharding at extreme scale, predictable performance, easier replication for read-heavy workloads.
For modern apps, Postgres usually wins on ecosystem alone - Prisma and Drizzle both treat it as a first-class citizen. But since PlanetScale now sells Postgres too, "I want Postgres" is no longer a reason to pick Neon over PlanetScale by itself. The reasons that still favor Neon are pricing and the free tier, not the engine.
The Branching Experience
Both offer database branching - create a copy of your database for testing or development. Git-like workflow for databases.
Neon uses copy-on-write: branches are instant and only store changed data, and extra branches now run $1.50/branch-month on paid plans. PlanetScale's original MySQL product copies the full database on branch. Their new Postgres product supports branching too, but it's young - fewer people have stress-tested it in production.
For large databases, Neon's copy-on-write approach is still faster and cheaper to operate day to day. PlanetScale has a more mature branch-management UI from its MySQL years, but Neon's approach remains the more practical default for most teams.
The Foreign Key Thing (Mostly Resolved)
This used to be a clean dealbreaker: Vitess didn't support foreign key constraints at the database level. That's no longer accurate. Foreign key constraints have been generally available on PlanetScale's MySQL product for unsharded databases since early 2024 - the database enforces them, not just your ORM. Sharded databases still don't support them; if you're at the scale where you need sharding, ask your account rep.
PlanetScale's new Postgres product supports foreign keys natively, same as any Postgres install, including Neon's. So "no foreign keys" is no longer a reason to avoid PlanetScale outright - it's a caveat that only bites you if you're sharding on the MySQL side.
The Verdict
Use Neon if: You want a free tier that's actually usable, Postgres, and instant branching. Post-acquisition pricing is aggressive and Databricks isn't squeezing it - yet. This is still most new projects.
Use PlanetScale's new Postgres if: You want PlanetScale's operational maturity (HA, failover, connection pooling) without the Vitess/MySQL lock-in, you're fine paying from day one, and $5/mo entry pricing is a non-issue for your project.
Use PlanetScale's MySQL/Vitess if: You're already on it, need proven horizontal sharding at extreme scale, or your company standardized on the workflow years ago and migrating isn't worth it.
Consider Supabase if: You want Postgres plus auth, storage, and realtime. It's a bigger package but might be all you need.
Neon has a permanent free tier, Databricks-subsidized pricing, and instant branching. PlanetScale still hasn't brought back a free tier - not even for their new Postgres product, which is genuinely good but starts billing at $5/mo from day one.