Why Single‑Node MySQL Won’t Scale and How to Move to Distributed Databases

Even non‑programmers get excited when comparing NAS devices, considering RAID level, speed, and ease of use; similarly, developers must focus on data storage and access.

Initially, out‑of‑the‑box MySQL is the default choice for enterprises because of its popularity and mature ecosystem, but relying solely on MySQL soon reveals serious issues.

These issues include overly large single tables (e.g., over 5 million rows), massive single‑instance databases exhausting resources, and read request volumes that severely impact write performance.

Single tables become too large, making queries costly.

Single databases grow too big, straining resources.

High read traffic degrades write operations.

Consequently, concepts like database partitioning, read/write separation, and sharding emerge. Historically, Chinese internet companies often inserted middleware to address these problems, but as distributed database technology matures, the “magic” moves down to the database layer itself.

Traditional sharding middleware (e.g., TDDL, Cobar, MyCat, ShardingSphere) has largely been superseded by native distributed databases. While middleware can still be used, it often adds operational overhead and limited functionality.

NoSQL systems such as Elasticsearch and Cassandra have long supported sharding and replication natively, and relational databases are now following suit with distributed implementations that incorporate Raft‑based consensus for reliability.

Cloud providers now offer enhanced MySQL services (Aurora, PolarDB) and pure distributed databases (TiDB, OceanBase). Switching to a compatible distributed store can simplify architecture, though teams must adapt to new concepts like distributed indexing.

In the long run, distributed databases represent the inevitable direction for relational data, while sharding middleware will gradually become a legacy solution for legacy workloads.