Database sharding: splitting data across servers
When one database server can no longer hold your data or writes, you shard. Learn the strategies, the pain points and why sharding should be a last resort.
Sharding splits one large dataset into smaller parts called shards, and each shard lives on its own database server. Every row belongs to exactly one shard. It is how a write-heavy system scales beyond one machine.
The shard key
You choose a shard key (for example user_id) that decides where a row goes. A good key spreads data and traffic evenly and appears in most queries.
Strategies
- Range-based: users 1 to 1M on shard A, 1M to 2M on shard B. Easy for range queries, but new users all hit the newest shard.
- Hash-based:
hash(user_id) mod Npicks the shard. Spreads evenly, but adding a shard moves lots of data (consistent hashing fixes this, see that part). - Directory-based: a lookup table maps each key to a shard. Flexible, but the lookup is a new dependency.
Problems you inherit
- Hot shards. One celebrity user or one busy tenant overloads a single shard.
- Cross-shard queries. A join or total across shards is slow and complicated. Design so most queries stay within one shard.
- Transactions across shards are hard. Avoid them, or accept eventual consistency.
- Resharding. Changing the number of shards later is a big migration.
- Operations. More servers to back up, monitor and upgrade.
Do it late
Before sharding, try: better indexes and queries, caching, read replicas, vertical scaling and archiving old data. Many systems never need sharding.
Takeaway: shard only when writes or data size truly exceed one server, pick the key carefully, and design queries to stay inside a shard.
Part 8 of 15 in the System Design series. Previous: SQL vs NoSQL: how to choose a database.
