PlanetScale
MySQL-compatible serverless DB built on Vitess. Reintroduced free tier in 2024 after a controversial removal.
VISIT PLANETSCALEKey takeaway: MySQL needs to be a requirement rather than a preference before PlanetScale is the right call. The Vitess engineering underneath is excellent and horizontal sharding is genuinely solved there, but for greenfield work the Postgres options give you more ecosystem for less friction. Choose it when you are already MySQL-shaped and expect to outgrow a single primary.
Quick facts
- CategoryMySQL
- EngineMySQL
- PricingPaid
- LicenseProprietary
- Created2018
- GitHub starsclosed
- PostgresNo
- Edge-readyNo
What it is
PlanetScale is the serverless MySQL database built on Vitess (the YouTube-scale sharding system). Schema branching, deploy requests, no foreign keys (Vitess constraint). Removed the free tier in 2024 sparking criticism, then reintroduced a developer tier in 2025. Mature and well-engineered but the pricing and trajectory have been turbulent.
Best for
- MySQL-compatible workloads needing horizontal scale
- Teams used to Vitess sharding patterns
- Apps with schema migrations as a deployment primitive
When not to pick it
Skip PlanetScale for greenfield projects in 2026 unless you specifically need MySQL, Postgres options (Neon, Supabase) are stronger. Skip if the recent pricing volatility makes you nervous.
My take
PlanetScale's engineering is excellent but the trajectory has been bumpy. For new projects, Postgres serverless options usually win; for existing PlanetScale deployments at scale, the migration cost is real.
Vitess underneath, and the foreign-key tax
PlanetScale is Vitess productised, the sharding system built to keep YouTube's MySQL alive, wrapped in a developer experience that hides most of the machinery. The headline workflow is schema branching and deploy requests: you change the schema on a branch, open a request, and the change ships as a non-blocking online migration with a revert window. On a large table that is a materially better story than most managed MySQL. The cost of Vitess is that foreign keys are not part of the model, so referential integrity moves into your application code. If your existing schema leans on cascading deletes and database-enforced relations, that is not a config change, it is a rewrite of your data-integrity assumptions. Teams arriving from Postgres feel this immediately. Teams that already ran MySQL at scale gave up foreign keys years ago and will barely notice.
Trajectory risk is a real planning input
The engineering has never been the problem here. The trajectory has. PlanetScale withdrew its free tier, took sustained public criticism for it, then brought back an entry-level developer tier. Whatever you make of the individual decisions, the pattern matters when you are choosing infrastructure you expect to keep for five years, because side projects and internal tools are what get stranded when entry-level pricing moves. Plan as if the commercial terms will change again, and keep your schema and queries portable enough that a move to another managed MySQL is a weekend rather than a quarter. For an existing deployment already sharded on Vitess, the switching cost is high and staying is usually correct. For a new project with no MySQL constraint, Neon or Supabase is the lower-risk starting point.
Frequently asked questions
Does PlanetScale support foreign keys?
Not the way a single-node MySQL or Postgres install does. Vitess, the sharding layer PlanetScale is built on, does not treat foreign keys as a first-class primitive, so referential integrity is expected to live in your application. Plan for that before migrating a schema that depends on cascading deletes and database-enforced relations.
Is PlanetScale free?
An entry-level developer tier exists again, reintroduced after the earlier free tier was withdrawn. Serious production use sits on paid plans. The point that matters for planning is not the current price but the volatility: entry-level terms on this product have moved before, so do not build a long-lived internal tool assuming they will not move again.
PlanetScale or Neon for a new project?
Neon, unless MySQL compatibility is a hard requirement. Neon gives you real Postgres, branching that covers the same preview-environment workflow, foreign keys, and a much larger extension ecosystem. PlanetScale earns the pick when you already run MySQL, already think in Vitess sharding patterns, or need horizontal scale beyond a single primary.
Links
Compare PlanetScale side-by-side
Similar tools you should also consider
If PlanetScale is your pick, the next conversation is short
The 30-min call is where your database choice becomes a real architecture, a migration plan if you are switching, and a price range you can take to your stakeholders. Describe your stack, your scale, your data shape. I tell you whether PlanetScale is genuinely your fit.