Why Single‑Node MySQL Is No Longer Enough: Embrace Distributed Databases

Even users who don’t code notice storage choices like NAS, but developers must focus on how data is accessed and stored.

MySQL has long been the default database for enterprises because of its popularity and mature ecosystem, yet relying solely on a single MySQL instance soon reveals serious drawbacks.

Tables exceeding millions of rows become slow to query.

A single instance exhausts CPU, memory, and storage resources.

High read traffic degrades write performance.

These problems give rise to concepts such as database sharding, read/write splitting, and other scaling techniques.

Historically, many Chinese internet companies addressed these issues by inserting middleware between the client and MySQL, but as distributed database technology matures, the “magic” is moving down to the database implementation layer itself.

Various implementation layers can be used:

Simple AOP or interceptor wrappers on MyBatis/JPA (the most naïve approach).

JDBC‑level drivers that rewrite DataSource, Connection, Statement, and ResultSet to route queries in memory, though they require maintaining physical tables and are limited to Java.

Proxy middleware that pretends to be a MySQL server, handling client requests without the client needing to know the underlying database, at the cost of additional operational overhead.

Over the years, many middleware projects appeared—TDDL, Cobar, MyCat, and finally ShardingSphere, which now stands out as the most active solution.

Beyond relational databases, NoSQL systems like Elasticsearch and Cassandra have long offered built‑in sharding and replication, eliminating the need for manual DBA intervention.

With protocols such as Raft becoming common, distributed relational databases now provide strong reliability and full MySQL compatibility, removing previous objections to using them.

Cloud providers also supply enhanced MySQL services (e.g., Aurora, PolarDB) and pure distributed databases (e.g., TiDB, OceanBase), making it easy to adopt a distributed architecture without extensive middleware development.

Adopting a distributed database does require teams to learn new concepts—especially around indexing and secondary indexes—but these growing pains are outweighed by long‑term scalability and stability.

In summary, distributed databases represent the future direction for data‑intensive applications, while sharding middleware is increasingly limited to legacy, “stock‑taking” workloads that will eventually be phased out.