MySQL platform

PlanetScale

PlanetScale is a MySQL-compatible database built on Vitess. This profile covers what it does, how it is priced, and where it stops being the right choice.

What the product actually does

PlanetScale runs MySQL on Vitess, the sharding layer YouTube built. The visible consequence is branching: a database branch is a schema-level copy that can be created in seconds, migrated, tested and merged, which makes schema changes reviewable in the same way code is.

The second consequence is that sharding is a platform concern rather than an application one. A database that outgrows a single node is split by the platform, and the application keeps issuing the same queries.

How pricing works once you are inside

Plans price on rows read and rows written, plus storage. The row-based meter is fair to a workload with a small hot set and punishing to one that scans. A reporting query that touches a million rows bills a million rows whether or not it returns anything useful.

The specific trap is that this makes analytics on the production database expensive by design. PlanetScale expects you to move analytical reads elsewhere, and the pricing is the mechanism that enforces the expectation.

Where it breaks down

Foreign keys were historically unsupported, and while the constraint has been relaxed the guidance still discourages them at scale. An application that relies on referential integrity has to enforce it in code.

The Vitess model also constrains what you can do with a connection: cross-shard transactions are not available, and queries that span shards have to be designed for.

What switching costs

Low at the SQL level — it is MySQL. Moderate at the operational level, because the branching workflow and the deploy-request process become how the team works.

Sources

PlanetScale public documentation and pricing page, read October 2026.