PlanetScale

I tested PlanetScale by deploying a serverless MySQL database backed by Vitess, configured with branching for schema migrations, deploy-request review workflow, and observed performance on a sample SaaS workload at roughly 800 transactions per second sustained. The cohort I had in mind was engineering teams wanting serverless MySQL with the Vitess horizontal-sharding capability for future scale, distinct from Neon (S159) which is serverless Postgres with similar branching philosophy and from Supabase (S158) which is BaaS bundle around Postgres.

The schema-migration deploy-request workflow is the actual differentiator. Creating a database branch for a schema change, opening a deploy request that runs the migration in shadow against production, getting a review-and-approve flow before merging the migration to main, and the automatic rollback path if performance regressed - all of this transforms schema migrations from the scariest deploy to a routine PR-style review. The Vitess foundation provides horizontal sharding capability that eventually becomes critical at scale where vertically-scaling Postgres or MySQL hit a wall. The connection pooler handles thousands of concurrent connections cleanly without exhausting database resources.

What broke me was the MySQL-versus-Postgres ecosystem reality plus pricing in 2026. Postgres has won the modern application database mindshare and most ORMs, observability tools, and reference architectures assume Postgres now: choosing MySQL via PlanetScale means more friction with downstream tooling than 5 years ago. The free Hobby tier was discontinued and minimum paid tier starts higher than Neon or Supabase free tiers, which raised the entry barrier for indie developers and side projects. Foreign key constraints have always been awkward in Vitess and PlanetScale historically punted on them in ways that surprised teams migrating from traditional MySQL deployments.

PlanetScale is the right pick for engineering teams committed to MySQL with Vitess sharding capability as a future-proofing requirement, especially when the schema-migration workflow alone justifies the cost. Skip it if you are starting fresh on a modern application stack where Postgres is the safer ecosystem choice (Neon or Supabase fit better), if your scale realistically never crosses the threshold where Vitess matters (a single Postgres instance handles most SaaS workloads), or if your budget cannot absorb the post-Hobby pricing minimum versus competitor free tiers.