Vitess v24.0.2 keeps MySQL while distributing the data
Vitess v24.0.2 sits between applications and multiple MySQL instances. Applications connect to VTGate through the MySQL protocol, and VTGate routes each query to the right shard. VTTablet runs beside MySQL to manage queries, replication, and tablet state. A topology service such as etcd, ZooKeeper, or Consul stores the cluster view. The design lets teams split and merge shards without teaching every application where rows live, which is the main reason to accept another layer in the database path.
Our fd0e84b checkout was 91.6 MB with 5,118 files and about 1,530,255 lines of source. The repository includes 49 CI workflow files, a Dockerfile, and a tests directory. That size reflects a full database platform: query planning, proxying, tablet management, topology adapters, replication workflows, backup tools, schema changes, administration, and client drivers all live in the project. Evaluating only VTGate latency or a local tutorial would miss the operational decisions that make or break a production Vitess deployment.
The 416-package install is the easy part
Our sandbox installed 416 packages in 74 seconds and the source build completed in 252 seconds. The official local guide asks for MySQL and etcd, then starts several MySQL processes for its example cluster. It recommends more than 4 GB of memory and 20 GB of free disk. Those requirements are reasonable for a database lab, but they make Vitess a poor fit for a developer who wanted a lightweight MySQL proxy. Docker images and the Kubernetes operator change packaging, not the number of moving roles.
The build passed in our 3-CPU, 8 GB unprivileged container, yet a functioning cluster still needs credentials, topology availability, backup storage, alerting, and capacity rules for both tablets and gateways. The local source guide calls Ubuntu the only fully supported operating system. It also warns that AppArmor or SELinux can prevent Vitess from launching MySQL in nonstandard data directories. Production teams should build their evaluation around the target scheduler and security controls instead of treating the local shell scripts as deployment architecture.
What happened when we ran it
Our install succeeded in 74 seconds, adding 416 packages, and the build succeeded in 252 seconds. The test command continued for 506 seconds before returning exit code 1. Its Go summary recorded 36 passed and 7 failed of 43. Those are the only pass and failure counts our run supports. We did not measure query throughput, reshard speed, failover time, or storage efficiency, so none of those outcomes should be inferred from a successful compile or from the repository's production history.
The final lines came from vitess.io/vitess/go/vt/wrangler/testlib, where planned reparent scenarios logged failed replica promotion and messages saying some replicas failed to reparent. That package ended with FAIL. The tail does not identify the cause of the other failed results and does not prove a defect in a live cluster. Still, 7 failed results after 506 seconds require triage before a team trusts this commit as its base. Re-run the same packages in the intended environment and account for every failure.
Seven failed results make reparenting drills mandatory
The 7 failures in our 43-result summary intersect with a part of Vitess that operators cannot treat casually: moving primary responsibility between tablets. The log tail names PlannedReparentShard, and current issue activity includes separate reports about reparent and traffic-switching behavior. Open issue 20923 says a caller can switch writes before all read tablet types, producing stale reads and leaving a Reshard workflow unable to complete. That report concerns a specific command order and version, so it should become a regression case rather than a blanket claim about every reshard.
The checkout's 1,530,255 source lines also include defenses and workflows accumulated over a long production history. That maturity helps only when operators follow the safe paths. Write a runbook for emergency and planned reparenting, backup restore, reshard cancellation, and topology loss. Exercise it under the same MySQL version and scheduler used in production. A distributed database can return correct queries for months while an untested recovery path waits for the worst possible day to reveal itself.
MySQL compatibility changes at the shard boundary
Vitess v24.0 documents MySQL protocol compatibility alongside explicit differences. Single-shard transactions provide MySQL's default repeatable-read semantics, while multi-shard transactions use read-committed behavior; two-phase commit is available for atomic distributed writes. The guide also maintains a list of unsupported queries and calls out behavior for prepared statements, stored procedures, temporary tables, user-defined functions, and cross-shard work. Schema and framework queries deserve their own tests because compatibility at connection time does not guarantee identical planning across keyspaces.
Our 91.6 MB checkout built successfully, but its 506-second test run shows why a serious trial must go beyond compilation. GitHub recorded a push on August 27, 2026, and listed 21,265 stars with 1,099 combined open issues and pull requests. Release v24.0.2 arrived on June 24 with fixes across backup, topology, query serving, replication, VTGate, VTTablet, and security. Vitess is active and mature enough for large MySQL estates. Its value appears when sharding pain already exceeds the cost of owning this many database components.