Sharding exhausted at 4TB, replaced by a horizontally scalable SQL cluster
Distributed SQL — TiDB
Where they started
The application had been manually sharded across twelve MySQL instances. Cross-shard queries were handled in application code, and adding a shard required a release.
The problem, precisely
Sharding was consuming engineering capacity faster than the growth it was meant to absorb, and the schema could no longer change without a coordinated deployment.
What we did
Migrated by workload class rather than by table — starting with the least transactional domain — and kept the old shards live and writable until each domain had been verified for a full traffic cycle.
Delivered
- TiDB cluster sized with a documented horizontal scaling procedure per component
- TiCDC pipeline from the legacy shards with row-count and checksum verification
- Migration by domain: read-only first, then writes, then shard retirement
- Placement rules and split configuration tuned for the hot tables
- Backup, restore and node-failure runbooks, each exercised once
Technologies used
Measured result
Every number below was measured and reported to the customer. Where we do not have a measured figure, the entry is a fact rather than a percentage — we would rather be precise than impressive.
- 12 → 1 application shards replaced by one logical cluster
- 0 application releases required to add capacity
- 6TB in production with no resharding work
- 4 min measured snapshot restore into a scratch cluster
Migrate distributed SQL by workload domain, never by table. Domains have boundaries your application already respects; tables do not.