PlanetScale is one of the most technically serious database products on the market. It's built on Vitess — the sharding layer that ran YouTube's MySQL — and its schema-change workflow (branches, deploy requests, non-blocking migrations, one-click revert) is genuinely the best in the MySQL world. If you're operating MySQL at the scale where sharding is a real conversation, PlanetScale earns its reputation.
But since the free Hobby tier was retired in April 2024, the entry price has a floor, and a lot of teams have been asking the same question: what do I actually need here? If the honest answer is "a reliable managed MySQL with backups," you're paying for a sharding architecture you'll never invoke. Meanwhile PlanetScale itself has broadened — adding Metal (NVMe-backed instances) and, in 2025, a Postgres offering — which tells you something about where demand went.
Here's a fair look at the alternatives, sorted by what you're actually optimizing for. PlanetScale's current pricing lives at [planetscale.com/pricing](https://planetscale.com/pricing) — I'll keep all pricing claims general, because they change.
First, be honest about why you're leaving
Three different exits, three different destinations:
- 1Cost floor. You wanted a free or cheap tier for side projects and staging. PlanetScale no longer plays there.
- 2You don't need Vitess. Sharding, connection-handling at extreme scale, online DDL at billions of rows — if your database is 20 GB and growing slowly, a well-run single-primary MySQL covers you for years.
- 3Vitess trade-offs annoy you. The sharded architecture historically constrained things like foreign key constraints (support came later) and shapes how you write certain queries. Some teams never notice; others fight it weekly.
1. TiDB Cloud — distributed SQL, MySQL protocol
TiDB is a distributed database that speaks the MySQL wire protocol, from PingCAP. Its serverless tier has a genuinely usable free quota, and the architecture gives you horizontal scale without Vitess's sharding-key ceremony — plus HTAP (analytical queries against the same data via TiFlash).
Strengths: the closest thing to "PlanetScale-class scale with a free entry point." Elastic, serverless, MySQL-compatible enough that most ORMs just work.
Trade-offs: "MySQL-compatible" is not "MySQL." It's a different engine underneath — different optimizer, different edge cases, a compatibility gap list you should read before migrating ([docs.pingcap.com](https://docs.pingcap.com/tidbcloud/)). For latency-critical single-row workloads, a distributed engine has physics to pay.
Pick it when: you want distributed scale and are migrating a codebase, not lifting a binary dump byte-for-byte.
2. Amazon RDS / Aurora MySQL — the incumbent
Boring in the best way. RDS MySQL is actual MySQL; Aurora is AWS's rebuilt storage layer with MySQL compatibility, faster failover, and up to 15 read replicas.
Strengths: operational maturity nothing else here matches — VPC isolation, IAM, cross-region replicas, compliance paperwork, and fifteen years of Stack Overflow answers. Pricing is usage-based across instances, storage, and I/O — see [aws.amazon.com/rds/aurora](https://aws.amazon.com/rds/aurora/).
Trade-offs: you inherit the ops. There's no deploy-request workflow — schema changes at scale mean [gh-ost](https://github.com/github/gh-ost), pt-online-schema-change, or leaning on MySQL 8's ALGORITHM=INSTANT DDL where it applies. And the bill takes a spreadsheet to predict.
Pick it when: you're already on AWS, or your compliance team is doing the picking.
3. PandaStack — managed MySQL next to your app
Full disclosure: this is us, so apply the appropriate discount. PandaStack is a developer cloud platform — container apps, static sites, edge functions, cronjobs — with managed databases built in: MySQL (5.7 and 8.x in production today), PostgreSQL, MongoDB, and Redis, orchestrated by KubeBlocks on GKE.
The model is deliberately different from PlanetScale's. There's no sharding layer and no deploy-request workflow — these are well-run managed instances, not distributed MySQL. What you get instead is proximity and predictability: provision a MySQL instance, attach it to your app, and DATABASE_URL is injected automatically. No credential copying between dashboards, no cross-provider hop on every query.
Strengths: flat pricing you can hold in your head — Free at $0/mo (1 database, 50 connections, 7-day backup retention), Pro at $15/mo (300 connections, 15-day retention), Premium at $25/mo (1,000 connections, 30-day retention). Daily plus on-demand backups. And the app side comes with it: git-push deploys, live build logs, custom domains with automatic SSL.
Trade-offs, honestly: if you're leaving PlanetScale because you've outgrown single-primary MySQL, we are not the answer — that's TiDB or Vitess territory. Free-tier databases get a small storage volume, fine for dev and hobby, not heavy production. And we're a newer platform with a smaller ecosystem than anything else on this list.
Pick it when: your app and database belong together, your MySQL is measured in gigabytes not terabytes, and you want a flat bill.
4. Self-hosted Vitess — the engine itself
Vitess is open source and CNCF-graduated ([vitess.io](https://vitess.io)). Everything that makes PlanetScale scale is available to run yourself on Kubernetes.
Strengths: no per-row or per-branch economics — your infrastructure, your cost curve. Full control.
Trade-offs: Vitess is a serious distributed system. You need people who understand vtgate, vttablet, topology services, and resharding operations — realistically a platform team, not a side quest. The gap between "runs in a demo" and "survives a resharding under load" is enormous.
Pick it when: you have genuine Vitess-scale problems and the engineering headcount to own them. If you have to ask whether you do, you don't.
5. The Postgres path — Neon, Supabase, and friends
A meaningful share of "PlanetScale alternatives" searches end with a database migration, not a provider migration. The Postgres ecosystem — Neon's serverless branching model, Supabase's full-backend bundle — has absorbed a lot of the workflow innovation that made PlanetScale special. Even PlanetScale launching its own Postgres product in 2025 reads as an acknowledgment.
Strengths: free tiers exist across the Postgres ecosystem, branching workflows exist (Neon, Supabase), and the extension ecosystem (PostGIS, pgvector) is unmatched.
Trade-offs: this is a real migration. MySQL and Postgres differ in SQL dialect, case-sensitivity behavior, AUTO_INCREMENT vs sequences, upsert syntax, and a hundred small ORM behaviors. Tools like pgloader do the heavy lifting, but budget actual engineering time, and expect the long tail in your least-tested queries.
Pick it when: you were MySQL by inertia rather than conviction, and you're touching the data layer anyway. (For what it's worth, PandaStack runs managed Postgres 14.x and 16.x too, so the app-attached model above works on either side of this fork.)
How I'd decide
- You genuinely need horizontal scale → stay on PlanetScale, or TiDB Cloud if the cost floor is the issue.
- AWS-native or compliance-driven → Aurora/RDS, plus gh-ost for schema changes.
- Platform team with Vitess-scale problems → self-host Vitess, eyes open.
- App + database together, flat bill, gigabyte-scale data → PandaStack.
- Willing to switch engines → the Postgres ecosystem is where the momentum is.
Whatever you choose, do one thing before migrating production: restore a backup on the new provider and point a staging build at it. Retention numbers on a pricing page are a promise; a completed restore is a fact.
If the app-attached managed MySQL model sounds like your shape of problem, you can try it at [pandastack.io](https://pandastack.io).