Sharding.
Splitting one giant phone book into A–M and N–Z so two people can search at once.
A single database server has limits — only so much disk, memory, and CPU. When your data outgrows one machine, you cannot just keep buying a bigger one forever.
Sharding splits the data across several machines, each holding one slice. Together the slices hold everything, and each machine only has to deal with its own share.
- My arms hurt.1
One phone book has grown too thick and busy for a single person to handle.
- 2
A bigger book only goes so far — eventually you can’t just buy a heavier one.
- 3
So you split it: A–M in one book, N–Z in another. Each slice holds part of the whole.
- 4
A lookup goes straight to the right slice — and two people can now search in parallel.
- 5
Choosing the split is the whole game — keys are hashed so the load spreads evenly.
- Why is it all coming to me?!6
Pick badly and one slice gets the celebrity account: a hot shard, swamped while the rest nap.
Choosing the key is the whole game
A good shard key spreads data and traffic evenly, so every machine does a fair share. A bad one creates a "hot shard" — one machine that holds the celebrity account or the busiest region and gets swamped while the others nap.
Keys are usually hashed so the spread is even and predictable, rather than splitting on raw alphabetical ranges where one letter might be far more common.
What gets harder
Once data is split, questions that need rows from many shards (counting all users, joining across them) become slower and more complicated, because the system has to talk to several machines and combine the results.
So sharding is a deliberate trade: near-limitless scale, paid for with more complexity. You reach for it when one machine genuinely cannot keep up, not before.