Why and How to Implement Database Sharding: Strategies, Middleware, and Best Practices

Why Sharding?

As a startup or fast‑growing company, user registrations can jump from hundreds of thousands to tens of millions, causing daily active users and per‑table row counts to explode; a single database can no longer handle the concurrent QPS or storage, making sharding (splitting databases and tables) a necessity.

Sharding (Table Splitting)

When a table reaches tens of millions of rows, query performance degrades. Splitting the table into multiple tables keeps each table’s row count within a manageable range (e.g., 2 million rows), improving SQL execution speed.

Database Sharding

When a single database’s concurrent capacity approaches its limit (around 1 000–2 000 QPS), you can distribute data across multiple databases, each handling a portion of the load, thereby increasing overall throughput and reducing disk usage.

Before Sharding

After Sharding

Concurrency Support

MySQL single‑instance cannot sustain high QPS

Multiple MySQL instances raise concurrency by several folds

Disk Usage

Single‑instance disk nearly full

Multiple instances greatly lower disk utilization per server

SQL Performance

Large table makes SQL slower

Reduced table size improves execution efficiency

Common Sharding Middleware

Cobar – Alibaba’s proxy‑layer solution (no longer actively maintained, lacks read/write splitting, stored procedures, cross‑db joins, pagination).

TDDL – Taobao’s client‑layer solution (supports basic CRUD and read/write splitting, but depends on Alibaba’s Diamond config system).

Atlas – 360’s proxy solution (community inactive for years).

Sharding‑jdbc (now ShardingSphere) – Dangdang’s client‑layer solution, supports sharding, read/write splitting, distributed ID, flexible transactions; actively maintained.

Mycat – Proxy‑layer solution derived from Cobar, feature‑rich and popular, but requires deployment and operational effort.

In practice, Sharding‑jdbc and Mycat are the two most viable choices. Sharding‑jdbc is lightweight, requires no extra deployment, and offers high performance, but upgrades require changes in every client application. Mycat needs its own deployment and higher O&M cost, yet it is transparent to downstream projects and suits large enterprises with many services.

How to Split a Database?

Horizontal Partitioning copies the same schema across multiple databases/tables and distributes rows based on a sharding key, allowing higher concurrency and storage capacity.

Vertical Partitioning splits a wide table into multiple tables (or databases) with different column sets, placing frequently accessed columns in one table and less‑used columns in another to improve cache efficiency.

Common sharding strategies include:

Range‑based: each database holds a continuous range (e.g., by time). Simple to add new shards but can create hotspot issues.

Hash‑based: data is distributed evenly by hashing a sharding key, balancing load but making expansion more complex due to data migration.

Choosing the right approach depends on your workload characteristics and growth expectations.