// the find
vitessio/vitess
Vitess is a database clustering system for horizontal scaling of MySQL.
Vitess is a MySQL sharding proxy that sits between your application and a fleet of MySQL instances, making them look like a single database. It originated at YouTube in 2011 and has been running at scale at Slack, Square, and others. If you're hitting the ceiling of a single MySQL node and don't want to rewrite your app for a different database, this is the serious option.
The VTGate query routing layer is genuinely clever — it parses SQL, rewrites cross-shard queries, and handles scatter-gather transparently so application code doesn't need to know shards exist. Online schema changes via VReplication let you run DDL on tables with millions of rows without locking, which is the thing that actually kills MySQL at scale. The connection pooling at the VTTablet layer dramatically reduces the connection count hitting each MySQL instance, which matters when you have hundreds of app servers. Upgrade/downgrade testing is baked into CI, which is rare and reflects real operational maturity.
The operational surface area is enormous — vtgate, vttablet, vtctld, vtorc, and a topology store (etcd or ZooKeeper) all need to run and stay healthy before you get a single query through. Getting it wrong locally is genuinely hard. Cross-shard transactions are supported but require 2PC and come with real caveats about atomicity guarantees that the docs undersell. The SQL compatibility layer has gaps — some MySQL features and query patterns just don't work, and you'll discover them at migration time, not during testing. The Kubernetes operator (vitess-operator) is the recommended production deployment path, which means adopting Vitess also means adopting significant Kubernetes complexity if you're not already there.