Vitess

What it is

Vitess sits in front of MySQL and turns a fleet of MySQL instances into something that behaves like a single, horizontally scalable database. It handles sharding, connection pooling, query routing, and resharding without app-level rewrites — your application still speaks MySQL wire protocol. Under the hood: VTGate (stateless query router), VTTablet (per-MySQL-instance proxy handling pooling and query rewriting), and a topology service (etcd/Consul/ZooKeeper) tracking cluster state. It's not a new database engine — it's an orchestration and routing layer over real MySQL.

Who builds it and why

Vitess was built at YouTube around 2010 to solve a very specific problem: MySQL couldn't scale to YouTube's write volume without manual, error-prone sharding. It was donated to CNCF in 2018 and graduated in 2019 — one of the earlier graduated projects, which says something about how long it's been battle-tested in production before hitting that status.

Today it's maintained by a mix of companies running it at scale (Slack, Square, HubSpot, GitHub's internal infra teams have all publicly discussed usage) plus PlanetScale, a company founded by the original Vitess creators that offers Vitess-as-a-service. That's an important dynamic to understand: PlanetScale employs many of the core maintainers, which means development is well-funded and active, but also means a commercial entity has significant influence over roadmap direction. 558 contributors is a healthy, non-single-vendor number, but check who's merging PRs if that matters to your risk assessment.

Production readiness signal

21K GitHub stars, commits as recent as July 2026, and CNCF graduated status — this is not an experimental project. It has run YouTube's MySQL fleet for over a decade and backs PlanetScale's entire commercial database product, meaning it's exposed to adversarial, paying-customer production traffic at scale. Apache-2.0 license, active release cadence (v24.0.2 as latest), Go codebase. The graduated status alone means it cleared CNCF's bar for governance, adoption breadth, and security process — that's a real signal, not a rubber stamp.

Who should use this

Teams running MySQL at a scale where vertical scaling and read replicas have stopped working — you're manually sharding, or about to. Organizations with existing MySQL operational expertise who want to keep MySQL semantics (transactions, existing tooling, existing ORMs) rather than migrating to a NewSQL engine with different consistency tradeoffs. Also a good fit if you're already running Kubernetes and want a database layer that fits the same operational model (Vitess has a well-supported Kubernetes operator).

Who should NOT use this

If your MySQL instance fits comfortably on one beefy box or a couple of read replicas, Vitess is pure operational overhead — you're adding VTGate, VTTablet, and a topology service cluster to solve a problem you don't have yet. Small teams without dedicated database/infra engineers will struggle: Vitess has a real learning curve and its own failure modes (topology service outages, VTGate routing bugs, resharding edge cases) that require someone who understands the internals, not just MySQL. If you need strong cross-shard transactional guarantees beyond what Vitess's semi-distributed transaction model offers, or you're not actually MySQL-compatible (heavy reliance on stored procedures, triggers, or MySQL features Vitess doesn't proxy well), look elsewhere. And if you want NewSQL-style global consistency without dealing with sharding keys at all, this isn't that.

Alternatives

• CockroachDB — distributed SQL with PostgreSQL wire compatibility and built-in geo-distribution; different consistency model, not a MySQL drop-in.
• TiDB — MySQL-compatible distributed database with HTAP support, more of a true distributed engine vs. Vitess's proxy-over-MySQL approach.
• PlanetScale (managed Vitess) — same engine, no operational burden, but you're paying for it and ceding infra control.

Pricing

Fully open source, Apache-2.0, no paid tier required to run it. You pay in operational effort (running VTGate, VTTablet, topology service) or you pay PlanetScale to run it for you.