AI
The Database Gap in Kubernetes-First Shops
Many teams run every workload in Kubernetes except the database. An RDS instance sitting outside the cluster is still the default choice for MySQL shops. Matt Lord opened by asking the room how many attendees run MySQL in Kubernetes. Few hands went up. That gap is the problem Vitess solves. It is a CNCF project that lets teams scale MySQL inside the cluster without abandoning the MySQL wire protocol their applications already speak.
Scaling One MySQL Instance to Thousands of Nodes
Vitess starts with a single MySQL instance and distributes the data layer across hundreds or even thousands of nodes. Applications and users see a single MySQL database throughout. No client-side changes are needed. Slack messages, GitHub pull requests, Square payments, Shopify orders, and Uber rides all pass through Vitess today. Those companies each run that data layer with a surprisingly small data team, according to Lord.
Sharding, Materializations, and Query Consolidation
Vitess provides sharding and resharding on demand. Materializations let operators create fact tables replicated across every shard, recovering data locality lost during distribution. Query consolidation addresses hot rows directly. If a million clients request the same row at once, Vitess queries the database once and fans the result out to all callers. Online schema changes are coordinated across every node automatically, removing the manual work that makes schema migrations dangerous at scale.
Automated Recovery With VTORC and the Kubernetes Operator
Automated recovery is the top operational concern as the data layer grows. Vitess addresses it with two components. VTORC monitors every node in the cluster and acts on any issue it detects. The Kubernetes operator handles the infrastructure side, managing the pods that back the cluster. Together they keep the cluster healthy without manual intervention. Failovers degrade gracefully, so users see a brief latency spike rather than errors.
Installing Vitess on Kubernetes in Minutes
Deployment starts with the Vitess operator, which has its own repository. Lord showed installing it directly from the Vitess repo for demonstration purposes. A single Vitess cluster custom resource definition describes the desired cluster state. Kubernetes reconciles from there. Within a couple of minutes a fully functioning Vitess cluster is running and ready to test. That speed is the point: teams can evaluate sharding and failover behavior without standing up any infrastructure outside the cluster.
Notable Quotes
it was a bit surprising to me that so many shops that are all in on Kubernetes are running everything in Kubernetes except their database. Matt Lord · ▶ 01:09
if you have a a really hot row and a million people come in, request the same row. Uh new Taylor Swift tweet or whatever the case may be, um it will only have to query the database once and then all of the clients can get that same um result. Matt Lord · ▶ 02:56
all those customers or users of the test that I mentioned before, they all have a very surprisingly small data team that’s managing that. Matt Lord · ▶ 04:52
Key Takeaways
- Vitess scales a single MySQL instance to hundreds or thousands of nodes transparently.
- VTORC plus the Kubernetes operator automate failover and cluster health without manual steps.
- A working Vitess cluster deploys from one CRD in a few minutes on any Kubernetes cluster.
About the Speaker(s)
Matt Lord is a Vitess maintainer at PlanetScale with more than 25 years in the database industry. He has worked on the producer side at MySQL and MongoDB and on the consumer side at WeWork and Etsy, giving him direct experience with MySQL scaling problems from both directions.