Why MySQL Must Evolve: From Single‑Node Limits to Distributed Databases

Even non‑programmers get excited when comparing NAS devices, but developers must pay close attention to data storage and access issues.

MySQL has long been the default choice for enterprises because of its widespread adoption and mature ecosystem, offering abundant tools and talent.

However, a MySQL‑centric approach soon encounters serious problems:

Single tables become too large (e.g., over 5 million rows), making queries sluggish.

A single database grows excessively, straining resources.

High read request volume severely impacts write performance.

These challenges give rise to concepts such as database sharding and read‑write separation.

Historically, many Chinese internet companies addressed these issues by inserting middleware layers, but as distributed database technology matures, these “magic” solutions are moving down to the database implementation layer itself.

The era of sharding middleware is waning; only ShardingSphere remains prominent, and the market for sharding technologies is shrinking.

Distributed databases—leveraging protocols like Raft—now provide reliable, MySQL‑compatible solutions, eliminating the need for separate NoSQL systems for many use cases.

Cloud providers also offer enhanced MySQL services such as Aurora, PolarDB, and pure distributed databases like TiDB and OceanBase, making migration to these platforms increasingly attractive.

Adopting distributed databases requires teams to acquire new skills, as traditional DBA expertise (e.g., index management) may no longer apply.

In the long run, distributed databases represent the inevitable trend, while sharding middleware will eventually disappear.