Splitting one database across many machines by a rule, when the data grows too big for a single machine to hold or serve.
Why it exists
A single database eventually holds more data or takes more writes than one machine can bear. Sharding exists to split the data across several databases by some key, so each machine holds and serves only its slice.
How it actually works
Replication copies the whole database; sharding splits it. When data outgrows any one machine, you divide it by a rule, say customers A to M on one machine, N to Z on another. Each machine (shard) holds a slice, and the system routes each request to the right shard.
This unlocks near-unlimited growth but adds real complexity: queries spanning shards get harder, and choosing the split rule well matters enormously. It's a step teams take only when they must.
A senior PM walks you through it
A junior PM, stuck
The data team says my loyalty report is slow because it is a cross-shard query, and that my Friday promo made the Dhaka shard hot. Two phrases, neither of which I understand. I approved the report and now I cannot tell if this is my fault, a temporary thing, or something that needs a real fix, and I have to report back on it.
Both phrases become obvious once you see how the orders got split. The orders table is too big for one machine, so it is cut into three shards by delivery area, one machine each. That split is what makes some queries fast and others slow. Below are the three shards with their row counts and two queries, one that touches a single shard and one that has to touch all of them. Read these and you can explain your report yourself.
The orders table split into three shards by delivery area
orders, sharded by delivery_area, one machine per shard
1 shard | delivery_area | rows
2 shard-dhaka | Dhaka | 780,000
3 shard-ctg | Chattogram | 140,000
4 shard-syl | Sylhet | 80,000
a query that names one area: goes to one shard, fast
>SELECT count(*) FROM orders WHERE delivery_area = 'Sylhet';
6-- routed to shard-syl only, answered in 40ms
your loyalty report: no area, so it fans out to every shard
>SELECT customer_id, sum(total) AS spent FROM orders
8GROUP BY customer_id ORDER BY spent DESC LIMIT 10;
9-- fans out to shard-dhaka, shard-ctg, shard-syl
10-- ERROR: statement timeout waiting on shard-dhaka
Click a step to see the lines it points at.
Mistakes I've seen
Reading cross-shard slowness as a normal slow query. A query that fans out to every shard waits on the slowest machine by design; tuning it like a single-table query misses that the shape of the split is the cause.
Ignoring the shard key when scoping a report. A query that names the shard key hits one machine and stays fast; one that omits it touches them all, so knowing the key tells you which reports will be cheap and which will crawl.
Treating a hot shard as temporary bad luck. If the shard key concentrates data, like area sending most orders to Dhaka, that machine is a standing bottleneck; the fix is the key choice, not waiting for traffic to calm.
Asking about the shard key too late. Once data is split by a key, changing it is a major migration; raise how will this be sharded while it is still a plan, not after the hotspots appear in production.
Report back: "The loyalty report spans all areas, so it is a cross-shard query that queries all three machines and waits on the slowest. The promo made the Dhaka shard the hottest, so it times out. It needs a different shape or a pre-aggregation, not a retry." You tied slowness to a missing shard key and a lopsided split, which is the skill.
Where a PM meets this
It's a late-stage scaling move; hearing it means the data is genuinely large, and changes get more complex and slower to make.
A bad shard key causes hotspots (one shard overloaded); "we sharded wrong" is an expensive lesson worth avoiding by asking early.
Hear it in a meeting
"Cross-shard queries are the slow part; the shard key was by region."