PlanetScale Vitess

CNCF-graduated MySQL-compatible sharding system, born at YouTube

I love my database GUI #database #mysql #postgresql

3.8(0 reviews)freeFounded 2010

free tieropen sourceself hostableapi access

Integrates with

AWS Kubernetes PostgreSQL NVMe SSD

Vitess is the CNCF-graduated, MySQL-compatible database system created at YouTube in 2010. It adds transparent horizontal sharding, online schema changes and automatic failure repair around MySQL; PlanetScale is its largest commercial contributor and managed offering.

What Vitess actually is

Our database row calls this product "PlanetScale Vitess", but the honest subject of a review here is Vitess itself — the open-source, MySQL-compatible database system that PlanetScale commercializes. Vitess was created inside YouTube in 2010 when the site's MySQL fleet was about to hit its serving ceiling: the team split reads and writes, added replicas, then sharded, and finally built a proxy layer that let applications stop caring which shard a query hit. That proxy layer became Vitess. It was open-sourced (first public commit February 2012), donated to the Cloud Native Computing Foundation in February 2018, and became a CNCF graduated project in November 2019 — the eighth ever, alongside Kubernetes and Prometheus.

The pitch has not changed much since the YouTube days: keep MySQL semantics, add transparent horizontal sharding, and keep the cluster running through failures, migrations and resharding without taking the application down. The CNCF's graduation announcement lists adopters including GitHub, JD.com, Pinterest, Slack, Square and YouTube itself, and the project journey report notes that PlanetScale has grown into the largest single contributor, having overtaken YouTube. If you want the case for Vitess in one sentence: this is the technology that let YouTube scale its database by a factor of more than 50 after sharding was introduced, and it is now neutral, foundation-governed infrastructure. Our category for it is /category/database-hosting.

Pricing: what you really pay

For the software itself the price is zero. Vitess is free, community-supported open source; you download it or use the Kubernetes operator and run it wherever you like. The database row's pricingModel of "free" is accurate for the project — what you spend is infrastructure and people, which brings us to the catch discussed below.

The commercial route is PlanetScale, which sells Vitess as a managed service and publishes a machine-readable price catalog (pricing.md) — a transparency practice we wish more vendors copied. Current published figures: Vitess Non-Metal clusters start at $39/mo per cluster node (the tier ranges up to $7,199 depending on node size), and Vitess Metal — local NVMe storage, up to 512 GiB RAM per node — starts at $609/mo per node (ranging up to $23,979). Around the Vitess core, PlanetScale has broadened into a Postgres line (single-node at $5/month for development and low-traffic workloads, Metal from $50/month, plus a high-availability three-node option) and "Neki", its horizontally sharded Postgres. There is no free tier on PlanetScale today — third-party pricing trackers score it zero out of ten on that criterion — so experimentation happens on your own hardware or on a paid cluster. PlanetScale Managed deploys the same data plane into your own AWS, GCP or Azure account, operated by PlanetScale's team.

For calibration: a three-node Vitess Non-Metal cluster is roughly $117/mo before storage, backup storage and egress, and the Metal tier starts around $1,827/mo for three nodes. That is the entry price for buying the YouTube-grade sharding story as a service. Below that kind of budget, the free software is the only option — and free assumes you can pay the operations cost instead.

Performance & infrastructure

Vitess sits between your application and MySQL (or MariaDB) as a set of stateless query routers (VTGates) in front of a fleet of tablet servers (VTTablets), with a topology service (etcd or similar) holding cluster state. The performance work is concrete: query rewriting, caching and connection pooling let concurrent client connections reach orders of magnitude beyond a traditional MySQL deployment — Vitess's own project page tracks this with nightly published benchmarks at benchmark.vitess.io. We have not run those ourselves and we would not quote numbers we have not measured; the useful fact is that the benchmarking is public and continuous.

On durability and operations, Vitess automatically detects and repairs primary failures, and both data migrations into Vitess and resharding operations within it run with near-zero downtime (live resharding carries minimal read-only windows). Schema changes run online in the background — the "non-blocking schema change" machinery is one of the most-loved features, though the docs are honest that Online DDL interacts poorly with tables carrying foreign keys. Point-in-time recovery exists: since v18 you can restore to a timestamp without running a binlog server, and GTID-position recovery landed in v17. Backup and restore tooling is built in, but you operate it — backups go to storage you provide and manage.

Compatibility is "MySQL wire protocol" rather than full MySQL dialect parity. The query planner has improved substantially (complex aggregations, subqueries, derived tables), and Vitess 18 delivered the compatibility milestone most people ask about: Vitess-managed foreign keys, including importing data with foreign-key relationships intact. The scope is deliberately narrow — shard-scoped constraints only, with cross-shard foreign keys still on the roadmap. The old blanket statement that Vitess has "no foreign key support" is out of date and we have corrected it in our database.

Where it falls short

The headline limitation is operational. Self-hosting Vitess means running VTGates, VTTablets, a topology store, and (in the standard deployment) a Kubernetes cluster with the Vitess operator — plus backups, monitoring, upgrades, resharding campaigns and schema migrations. The community is active (CNCF tracks 2,159 total contributors and rates project health "Healthy" at 78), and the documentation is good, but there is no support contract attached to the free software. If your team cannot describe how it would execute an online resharding at 2 a.m., you are buying PlanetScale or another managed distribution, not downloading Vitess.

Second, the compatibility gaps that remain are real. Managed foreign keys are shard-scoped only, so a schema with cross-shard relationships must either co-locate rows (shared vindexes) or leave constraints unmanaged and handle integrity in the application. Cyclic foreign keys are rejected. With managed foreign keys, statements like REPLACE INTO and INSERT ... ON DUPLICATE KEY UPDATE are restricted. None of this is exotic — it is exactly the set of things that make a distributed database honest about its trade-offs — but teams migrating a rich legacy schema should audit it before committing.

Third, cost floor. Vitess solves the "my database outgrew one node" problem. It is emphatically the wrong tool before that point: all of the operational machinery buys you nothing on a workload a $8/month VPS or a single managed MySQL instance would handle. And the managed versions price from $39/mo per node upward, which is more than most side projects should pay for a database.

Finally, a housekeeping note: our database previously framed this entry as PlanetScale's serverless MySQL. The framing was wrong in both directions — Vitess is neither serverless nor, strictly, a PlanetScale product. The row keeps the slug it has; the review covers Vitess, with PlanetScale as the reference commercial offering.

Who should pick this

We'd pick Vitess when the workload is a MySQL-compatible relational dataset that no longer fits one primary: multi-tenant SaaS with large per-customer tables, high-throughput write paths, global applications needing many read replicas, or platforms preparing for sharding before it becomes an emergency. If your team already runs Kubernetes and has database operations experience, self-hosting Vitess is a legitimate way to get Google-scale tooling for the price of compute. If you want that tooling without the pager, PlanetScale is the cleanest purchase path, and the pricing catalog makes budgeting straightforward.

We'd look elsewhere when: a single MySQL/Postgres instance with replicas still fits, you need cross-shard foreign keys today, or your team has no database operations function — plain managed MySQL/Postgres in /category/database-hosting will be cheaper and calmer. A pragmatic pattern we endorse: model your schema for sharding early (stable vindexes, no cross-shard joins where avoidable), but stay on a single node until the numbers force the move; Vitess's migration tooling is specifically built to make that late jump near-zero downtime. For the compute that will host any of this, our /benchmarks pages cover the underlying server market.

Key takeaways

Vitess is free, CNCF-graduated (2019) infrastructure born at YouTube in 2010; adoption includes GitHub, Pinterest, Slack and YouTube itself.
It shards MySQL transparently to the application, with live resharding, online schema changes and automatic primary-failure repair.
Foreign keys have been supported since Vitess 18 (2023) — shard-scoped and managed by Vitess; cross-shard constraints remain future work.
The real cost is operations: a full Kubernetes-plus-VTGate footprint with no support contract unless you buy one.
PlanetScale sells it managed from $39/mo per cluster node (Metal from $609/mo per node) with a public pricing.md; there is no free tier there.
Right tool past one MySQL node, wrong tool before it; our overall view lands at 3.8/5.

Sources

Pros

Free, foundation-governed software with YouTube-scale production provenance since 2011
Horizontal sharding transparent to the application, with live resharding and near-zero-downtime migrations
Online, non-blocking schema changes across shards with monitoring and fine-grained controls
Automatic primary failure detection and repair; point-in-time recovery without a binlog server since v18
Active, healthy project — 2,159 contributors tracked by CNCF, with public nightly benchmarks

Cons

Real operational burden: VTGates, VTTablets, topology store and a Kubernetes operator footprint to run yourself
Foreign keys are shard-scoped only (managed mode since v18); cross-shard constraints are still future work
Compatibility gaps under managed foreign keys — REPLACE INTO and INSERT ... ON DUPLICATE KEY UPDATE restricted, cyclic FKs rejected
No support contract or SLA on the free software; PlanetScale is the primary paid route
Massive overkill below the scale where a single MySQL node stops being enough

Best For

Teams whose MySQL-compatible dataset no longer fits one node and who want sharding without rewriting the application — self-hosting Vitess with Kubernetes experience, or buying it managed through PlanetScale.