Why Single‑Node MySQL Is Dying and Distributed Databases Are the Future

Limitations of Single‑Node MySQL

When a MySQL instance grows beyond a single server, three fundamental bottlenecks appear:

Table size explosion – tables exceeding several million rows (e.g., >5 M) cause full‑table scans and index degradation, leading to slow queries.

Database‑wide resource exhaustion – the combined size of all schemas can saturate CPU, memory and storage, making routine maintenance (backups, vacuum, re‑index) impractical.

Read‑heavy workloads – a high volume of read requests competes with write operations, reducing write throughput and increasing latency.

These symptoms drive the adoption of techniques such as horizontal sharding (分库分表), read/write splitting, and other scaling patterns.

Sharding Middleware Approaches

Historically, many Chinese internet companies inserted a middleware layer that pretended to be a MySQL server. The middleware intercepts client connections, parses SQL, and routes statements to the appropriate physical shard. Prominent projects include:

TDDL

Cobar

MyCat

ShardingSphere (the most actively maintained today)

Typical implementation strategies are:

AOP / interceptor layer – wrap MyBatis, JPA, or other ORM frameworks with advice that rewrites SQL before execution. This is simple but invasive.

JDBC driver proxy – replace the standard DataSource, Connection, Statement, and ResultSet classes with custom implementations that keep routing metadata in memory. This provides transparent sharding for Java applications but requires maintaining a mapping between logical and physical tables.

MySQL protocol proxy – run a server that speaks the MySQL wire protocol, accepts client connections, and forwards queries to backend shards. The proxy hides routing logic from the client but introduces an additional service to operate and monitor.

Limitations of Middleware

While middleware can postpone the need for a distributed database, it brings its own drawbacks:

Operational overhead – the proxy or driver layer must be deployed, scaled, and kept in sync with schema changes.

Feature gaps – many middleware solutions do not fully support advanced MySQL features (stored procedures, GTIDs, complex transactions).

Language lock‑in – JDBC‑based proxies work only for Java; other ecosystems need separate adapters or cannot use the middleware at all.

Complexity migration – the logical‑to‑physical table mapping must be maintained manually, increasing the risk of inconsistency.

Native Distributed Relational Databases

Modern distributed databases implement sharding, replication, and strong consistency inside the storage engine, eliminating the need for an external proxy. Notable MySQL‑compatible systems include:

TiDB – a NewSQL database that uses the Raft consensus algorithm for distributed transactions and automatically splits tables.

OceanBase – a cloud‑native relational database with built‑in horizontal scaling and multi‑region replication.

Amazon Aurora – an AWS‑managed service that separates compute and storage, providing up to 15 read replicas with low‑latency failover.

PolarDB – Alibaba Cloud’s distributed MySQL service that shares storage across nodes for high availability.

These platforms offer:

Automatic data partitioning without manual table‑splitting.

Strong consistency guarantees via Raft or Paxos‑based protocols.

Built‑in high availability and fault tolerance (automatic leader election, replica promotion).

Full MySQL protocol compatibility, allowing existing client libraries to connect without code changes.

Choosing Between Middleware and a Distributed Database

The decision depends on the lifecycle of the service:

New services with rapid data growth – adopt a distributed database from the start to avoid later migration pain.

Legacy monolithic applications – a sharding middleware can be introduced incrementally to offload hot tables while the existing schema remains intact.

Key evaluation criteria include:

Operational maturity – does the team have expertise to run a distributed cluster?

Feature requirements – need for stored procedures, triggers, or specific MySQL extensions?

Latency and throughput targets – distributed databases often provide better read scalability.

Migration cost – how much effort is required to rewrite data access layers?

Migration Guidance

When moving from a sharding middleware to a native distributed database, follow these steps:

Assess schema compatibility – ensure that tables, indexes, and data types are supported by the target system.

Export logical‑to‑physical mapping – capture the current shard key and partitioning rules.

Provision a test cluster – deploy a small instance of the distributed database (e.g., TiDB cluster) and load a representative data subset.

Validate application behavior – run integration tests against the new cluster, focusing on transaction semantics and query performance.

Plan cut‑over – use dual‑write or replication tools to keep the old and new databases in sync during migration.

Decommission middleware – once confidence is established, retire the proxy layer and clean up routing configurations.

During the transition, keep monitoring key metrics (CPU, QPS, latency, replication lag) to detect regressions early.

Long‑Term Outlook

As Raft‑based protocols and cloud‑native architectures mature, distributed relational databases are becoming the default choice for scalable, highly available data storage. Sharding middleware will increasingly serve only legacy workloads that cannot be migrated immediately, and its functionality is gradually being absorbed into the core of distributed database engines.