Skip to content

Vitess Production Deployment

Three years operating Vitess in production for MySQL horizontal scaling — before managed databases converged on the same capabilities.

  less than a minute  

Running Vitess in production for three years teaches you where horizontal scaling actually bites: ops discipline, not demos. This is the record of what it took to run the system that powers YouTube’s MySQL fleet, at a scale far smaller than YouTube’s — and why that changes the calculus.

Challenge

A MySQL deployment outgrowing vertical scale: write volume and working set exceeding what a single well-tuned instance could absorb, with availability requirements that ruled out naive primary failover.

Approach

  • Unsharded first. Vitess managed topology, failover, and connection pooling while the data still fit in one shard — the operational win arrived years before the sharding win was needed.
  • Resharding as a rehearsed operation. VSchema-driven workflows, practiced on staging copies, with serving cutover and rollback drilled.
  • Honest cost accounting. Vitess bought scale with a distributed systems tax: new failure modes, a steeper on-call surface, and application-side query patterns that had to respect shard boundaries.

Result

Three years of stable production operation and a clear-eyed view of when the tax is worth paying. When managed Aurora converged on the workloads' actual needs, the migration off was as deliberate as the adoption on.