Cloud Parts

Vitess

A proxy layer, born at YouTube, that shards MySQL across many servers while the app still sees one database.

What it is
Relational databases
Type
Open source
Made by
Cloud Native Computing Foundation
License
Apache 2.0
Facts checked
6 October 2026
Website Source code

What it is

Vitess puts a layer of Go processes between your app and many ordinary MySQL servers. The app connects to VTGate with any MySQL driver. VTGate parses each query, looks up the VSchema, which says how each table is sharded, and sends the query to the right shards, merging results when it has to ask several. A keyspace is a logical database; in a sharded keyspace a vindex function such as xxhash turns each row’s sharding key into a keyspace ID, and each shard owns a range of IDs (-80, 80-). Next to every MySQL instance runs a VTTablet that pools connections, rewrites or kills harmful queries, and manages replication and backups. Cluster state lives in a topology service (etcd by default, ZooKeeper or Consul), which is not on the query path, so queries keep flowing if it is briefly down.

Operations are workflows. MoveTables and Reshard copy data to new keyspaces or shards with VReplication, verify it with VDiff, then switch reads and writes over with seconds of read-only time. VTOrc watches every shard and runs an emergency reparent when a primary dies; semi-sync replication is recommended so failover loses no data. Vitess supports MySQL and Percona Server 8.0 and 8.4; v24 is the last release with 8.0. It is free under Apache 2.0, a graduated CNCF project, runs on Kubernetes through an open-source operator, and is sold as a managed service by PlanetScale, founded by its co-creators.

Why teams pick it

  • Horizontal sharding of MySQL without sharding code in the app, and online resharding as data grows
  • Lightweight client connections multiplexed onto small MySQL pools, so thousands of connections are cheap
  • Automated failover with VTOrc, online schema changes, backups to S3, GCS or Ceph, and cell-aware multi-region layouts
  • Proven at scale: it served all of YouTube’s database traffic for years, and Slack, Square, GitHub and JD.com adopted it
  • Vendor-neutral governance under the CNCF since 2018, with PlanetScale as a managed option

Watch out for

  • Not all of MySQL: CALL works only on an unsharded keyspace or a targeted shard, CREATE PROCEDURE must go to MySQL directly, views in sharded keyspaces are experimental and read-only, and temporary tables work only unsharded
  • Cross-shard reads may be inconsistent with each other and run at READ COMMITTED; atomic cross-shard writes need 2PC mode, which costs about 50% more per write
  • Sharded tables lose auto_increment to Vitess sequences, and a poor sharding key turns common queries into expensive scatter queries
  • Many moving parts to run: VTGate, VTTablet per MySQL, vtctld, VTOrc and a topology cluster; prebuilt binaries are fully supported only on Ubuntu
  • MySQL and Percona only: MariaDB can be imported but not run, and MySQL 8.0 users must move to 8.4 after v24

Alternatives

What all relational databases have in common →
Alibaba Cloud PolarDBCommercialAlibaba Cloud’s cloud-native relational databases: MySQL- and PostgreSQL-compatible clusters whose compute nodes share one copy of the data on distributed storage, plus PolarDB-X, a distributed MySQL-compatible edition.CedarDBCommercialA PostgreSQL-compatible database rebuilt from scratch at TU Munich, running transactions and analytics on one copy of the data on a single server.Cloudflare D1CommercialCloudflare’s serverless SQL database that speaks SQLite, runs each database inside a Durable Object, and bills by rows read and written rather than by the hour.CloudNativePGOpen sourceA Kubernetes operator that runs highly available PostgreSQL with no Patroni and no StatefulSets: the Kubernetes API itself holds the cluster’s state.CockroachDBCommercialA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.MySQLOpen sourceThe long-standing open-source SQL database behind much of the web, built on the InnoDB engine.NeonCommercialServerless Postgres that keeps data in a shared storage layer, so compute can scale to zero and a branch of the database is a pointer, not a copy.PatroniOpen sourceA Python agent beside each Postgres server that elects one primary through etcd, Consul, ZooKeeper or Kubernetes, and fails over when it dies.Percona OperatorsOpen sourceFour free Kubernetes operators from Percona that run its builds of MySQL, PostgreSQL and MongoDB, each using the engine’s own replication and backup tools.PGO (Crunchy Postgres for Kubernetes)Open sourceCrunchy Data’s Postgres operator: Patroni in every pod for failover, pgBackRest for backups, and a declarative `PostgresCluster` resource on top.PlanetScaleCommercialManaged MySQL on Vitess and managed Postgres, with schema changes shipped through branches and deploy requests.PostgreSQLOpen sourceThe open-source relational database that most new projects start on, extensible enough to grow into many niches.ScramDBCommercialA brand-new, closed-source database that speaks the PostgreSQL protocol and promises transactions, analytics and vector search on one copy of the data; first builds shipped in summer 2026.SQLiteOpen sourceA complete SQL database in a library and a single file, with no server to run.TursoOpen sourceA from-scratch Rust rewrite of SQLite with concurrent writes, plus libSQL (an open-contribution SQLite fork) and Turso Cloud, which hosts many small databases on S3.

How it fits with other technologies

Move two tables to their own keyspace, then split it into two shards · bash

# 1. copy customer and corder out of the unsharded commerce keyspace
vtctldclient MoveTables --target-keyspace customer --workflow commerce2customer \
  create --source-keyspace commerce --tables 'customer,corder'
vtctldclient VDiff --target-keyspace customer --workflow commerce2customer create
vtctldclient MoveTables --target-keyspace customer --workflow commerce2customer SwitchTraffic
vtctldclient MoveTables --target-keyspace customer --workflow commerce2customer complete

# 2. shard customer by customer_id (xxhash vindex, sequences instead of auto_increment)
vtctldclient ApplySchema --sql-file create_commerce_seq.sql commerce
vtctldclient ApplyVSchema --vschema-file vschema_commerce_seq.json commerce
vtctldclient ApplyVSchema --vschema-file vschema_customer_sharded.json customer

# 3. after starting tablets for shards -80 and 80-, split shard 0 into them
vtctldclient Reshard --target-keyspace customer --workflow cust2cust \
  create --source-shards '0' --target-shards '-80,80-'
vtctldclient VDiff --target-keyspace customer --workflow cust2cust create
vtctldclient Reshard --target-keyspace customer --workflow cust2cust SwitchTraffic --tablet-types=rdonly,replica
vtctldclient Reshard --target-keyspace customer --workflow cust2cust SwitchTraffic
vtctldclient Reshard --target-keyspace customer --workflow cust2cust complete

The parts of a Vitess cluster#

Each is a separate process; a small test cluster runs them all on one machine, production spreads them across hosts or pods.

VTGate

stateless proxy

Speaks the MySQL protocol (and gRPC) to apps, plans queries against the VSchema and routes them to shards. Run as many as you need behind a load balancer.

VTTablet

one per MySQL

Sits beside each mysqld: connection pooling, query rules and limits, replication management, backups and the VReplication streams behind MoveTables and Reshard.

Topology service

etcd, ZooKeeper or Consul

A global store for keyspaces, shards and each shard’s primary, plus a local one per cell for its tablets. Used for discovery and locks, not for serving queries.

VTOrc

failure repair

A fork of Orchestrator that elects a primary for new shards, runs an emergency reparent when one dies, and fixes replication settings, following the keyspace’s durability policy.

vtctld and vtctldclient

control plane

The admin server and CLI for schema and VSchema changes, workflows and reparenting.

VTAdmin

web UI

A web UI (vtadmin-web) and API (vtadmin-api) for looking after clusters.

What changes when you shard MySQL with Vitess#

Within one shard, a query behaves as in MySQL. These are the differences once a keyspace has several shards.

In MySQLIn a sharded Vitess keyspace
TransactionsREPEATABLE READ within a shard; READ COMMITTED across shards, atomic only in 2PC mode
`auto_increment`Replaced by sequences: a single-row table in an unsharded keyspace hands out IDs in cached chunks
Stored proceduresCALL only on a targeted shard, IN parameters only, no result sets
ViewsExperimental, read-only, all tables in one keyspace
Temporary tablesNot supported
Joins and aggregatesMostly supported; VTGate merges results, and joins on the sharding key stay on one shard
Schema changesManaged online DDL across all shards, or plain DDL

See it in a real stack

No architecture uses Vitess yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2010–2026

In 2010 YouTube’s MySQL database was close to running out of capacity at peak. Read replicas helped until writes outgrew a single primary, and then the application itself had to know which shard held each row. Vitess, created that year, moved that logic out of the app into a proxy between the app and MySQL, which also handles failover, connection pooling and protection from bad queries.

At YouTube it ran on Borg, Google’s cluster manager, and served all database traffic for more than five years while YouTube’s user base grew more than 50-fold. It was also released as open source. Version 2.0 reached general availability in 2016. In February 2018 the CNCF accepted Vitess as an incubating project, the same year its co-creators founded PlanetScale to sell it as a service, and in November 2019 it became the eighth CNCF project to graduate.

Vitess showed that MySQL could be scaled out without changing databases, and companies such as Slack, Square and GitHub adopted it.

Why it’s built this way

A proxy instead of sharding logic in the app
YouTube’s code had to pick a shard before every query. Moving routing into VTGate let the app see one database while the data spread over many MySQL servers.
Keep real MySQL underneath
Each shard is still a MySQL primary with replicas, managed by a VTTablet beside it, so the storage engine, replication and tooling stay ones teams already trust.
Many small instances
Vitess recommends about 250 GB per MySQL server: smaller instances replicate, back up and restore faster, and an outage affects less data.
Built for a cluster scheduler
At YouTube it ran on Borg, so it was designed for processes that move between machines; the same design fits Kubernetes.

Timeline

  1. 2010

    Created at YouTube to scale its MySQL databases

  2. 2016

    Vitess 2.0 released

  3. 2018

    Accepted by the CNCF on 5 February; PlanetScale founded

  4. 2019

    Graduates from the CNCF on 5 November, the eighth project to do so

  5. 2026

    v24 adds cell-aware VTOrc; last release supporting MySQL 8.0

Sources21 · facts checked 6 October 2026

Improve this page on GitHub