Your database is slowing down. Queries that took 50ms now take 5 seconds. You've added indexes, optimized queries, and upgraded hardware. Nothing helps.
The problem isn't your queries. It's your data volume. A single database can only scale so far.
Sharding—splitting your data across multiple databases—is the solution. But it's also one of the most complex architectural decisions you'll make.
This guide covers when to shard, how to choose a sharding strategy, and the hidden costs nobody warns you about.
Sharding isn't always the answer. It adds significant complexity. Consider it only when:
| Signal | Threshold |
|---|---|
| Table size | > 500 million rows |
| Write throughput | > 10,000 writes/second |
| Read latency (p99) | > 500ms after optimization |
| Storage | Approaching single-node limits |
| Backup time | > 4 hours |
If you're not hitting these thresholds, vertical scaling (bigger hardware) or read replicas might be enough.
Data is split by ranges of a key value.
Shard 1: user_id 1 - 1,000,000
Shard 2: user_id 1,000,001 - 2,000,000
Shard 3: user_id 2,000,001 - 3,000,000
Pros:
Cons: