Database Sharding

What is database sharding?

Sharding partitions a database horizontally across multiple machines: each shard holds a subset of the rows, chosen by a shard key, so no single server holds everything. It’s how you scale writes and storage beyond what one machine can handle — the tool you reach for when read replicas (which only scale reads) aren’t enough because the write load or dataset size exceeds a single primary. It’s also one of the most consequential and hard-to-reverse decisions in a system’s life.

The shard key is everything

Choosing the shard key determines whether sharding helps or hurts, and it’s chosen early, when you understand the workload least. A good key distributes data and load evenly and keeps related data together so common queries hit one shard. The failure modes are brutal: a hot shard (a key like country where one value dominates concentrates load on one server, recreating the bottleneck you sharded to escape), and cross-shard queries (any query not scoped by the shard key must fan out to all shards and merge results — slow, and it destroys the isolation sharding provides). Once data is distributed by a key, changing that key means re-sharding the entire dataset — a migration so painful teams live with bad keys for years. Consistent hashing is the standard technique for distributing shards so adding capacity doesn’t reshuffle everything.

The complexity you inherit

Sharding forfeits things a single database gave you for free: cross-shard transactions (ACID across shards is hard-to-impossible — you get sagas and eventual consistency instead), cross-shard joins (do them in the application, or denormalize), unique constraints across shards, and simple aggregate queries. This is why the universal advice is shard last: exhaust vertical scaling (a bigger box), read replicas, and caching first, because each is far simpler. Many “we need sharding” situations are actually “we need an index” or “we need a cache.” Modern distributed SQL databases (CockroachDB, Spanner, Vitess) automate much of this — sharding you don’t hand-manage — which is increasingly the better answer than DIY sharding.

What people get wrong

• Sharding prematurely — inheriting distributed-systems complexity before exhausting the simpler scaling levers.
• A shard key that creates hot shards — concentrating load on one server and un-scaling the thing you sharded.
• Cross-shard queries everywhere: designing access patterns that ignore the shard key, forcing fan-out on every request.

Primary source: MongoDB — Sharding documentation