Learn the theory
Sharding & Replication: how it works
4 min read · Updated
One database server eventually runs out of disk, memory, CPU or write throughput. There are two classic ways out: replication (keep full copies of the data on several servers to scale reads and survive failures) and sharding (split the data so each server holds only a slice, scaling writes and storage). They solve different problems, cost different things, and are almost always used together.
In short
- Replication copies the same data to many servers: scales reads, adds failover, but not writes or storage.
- Sharding splits data across servers by a shard key: scales writes and storage, but queries without the key must hit all shards.
- Range sharding keeps ranges together but creates hot shards; hash sharding spreads load but kills range queries.
hash(key) mod Nremaps almost everything when N changes; consistent hashing moves only about 1/N of the keys.- Asynchronous replication has lag, so reads from replicas can be stale.
Scaling up vs scaling out
Vertical scaling (a bigger server) is simple and should come first, but it has a ceiling and a price curve that bends sharply. Horizontal scaling spreads the load over many commodity servers — which requires deciding where each piece of data lives.
| Technique | Data on each node | Scales | Main cost |
|---|---|---|---|
| Replication | Everything (a full copy) | Reads, availability | Lag and consistency questions |
| Sharding | A slice of the data | Writes, storage | Complex queries, resharding, operations |
Sharding strategies
| Strategy | How the shard is chosen | Good at | Weakness |
|---|---|---|---|
| Range | Key ranges per shard (ids 0–249 → shard 0…) | Range queries; easy to split a range | Sequential keys pile onto the last shard (hot shard) |
| Hash | hash(key) mod N | Even spread, no hotspots | Range queries hit every shard; changing N remaps almost all keys |
| Consistent hashing | Keys and shards are placed on a ring; a key belongs to the next shard clockwise | Adding/removing a shard moves ~1/N keys | More complex; needs virtual nodes for balance |
| Directory (lookup) | A table maps each key (or tenant) to a shard | Total flexibility, easy rebalancing of single tenants | The lookup service is a bottleneck and single point of failure |
What gets harder
- Queries without the shard key become scatter-gather: sent to all shards and merged, as slow as the slowest shard.
- Cross-shard JOINs and transactions need distributed coordination (two-phase commit, sagas) or must be avoided by design.
- Global uniqueness and ordering (auto-increment ids) need a different scheme, like UUIDs or Snowflake-style ids.
- Resharding — adding shards — means migrating data live. With
hash mod Nalmost every row moves.
Replication and lag
In primary–replica replication, every write goes to the primary, which streams its log to replicas. With asynchronous replication the primary doesn't wait, so replicas lag by milliseconds to seconds and a read right after a write may return old data (a stale read). Synchronous replication waits for replicas but makes writes slower and less available.
- Read-your-writes: after a user writes, serve their reads from the primary for a short while.
- Monotonic reads: pin a user's session to one replica so time doesn't appear to go backwards.
- Failover: if the primary dies, promote a replica — and risk losing the writes it hadn't received yet.
Using both
Large systems shard for write capacity and storage, then replicate each shard for read scaling and failover. Before any of that, make sure you've exhausted cheaper options: better indexes, caching, query fixes, a bigger server, and read replicas.
Frequently asked questions
- What is database sharding?
- Splitting a large dataset into smaller parts (shards), each stored on a separate database server, usually by a shard key such as user id. It scales writes and storage beyond a single machine.
- What is the difference between sharding and replication?
- Replication stores copies of the same data on multiple servers to scale reads and improve availability. Sharding stores different parts of the data on different servers to scale writes and storage.
- What is the difference between range and hash sharding?
- Range sharding assigns contiguous key ranges to shards, which keeps range queries local but can create hot shards. Hash sharding spreads keys by hashing, which balances load but makes range queries touch every shard.
- What is consistent hashing?
- A scheme that places shards and keys on a hash ring so that adding or removing a shard only remaps the keys adjacent to it (about 1/N of them), instead of remapping nearly all keys like hash mod N.
- What is replication lag?
- The delay between a write being committed on the primary and being applied on a replica. Reads from a replica during that window can return stale data.
- When should I shard my database?
- Only after cheaper options are exhausted: indexing, query tuning, caching, read replicas and vertical scaling. Sharding adds significant operational and application complexity.