# Vitess Production Deployment

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

---

LLMS index: [llms.txt](/llms.txt)

---

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.