103
sharding
Split rows across databases by a key. The key is the product decision. A bad key is a hot shard.
What is sharding?
A shard is a partition of the data: each node owns a slice, not a full copy. You shard when one machine cannot hold or write the set. Queries that need many shards become scatter-gather. Resharding moves rows and hurts.
Why does sharding matter when vibe coding?
Models shard on day one “for scale,” or they shard by a random id and then every inbox fans out to every node. Name the key and the query that must stay on one shard.
How do you do sharding?
Shard only when one node’s disk, write rate, or backup window is the proven limit. Pick a key you filter by (tenant, not a global timestamp). Keep transactions inside one shard.
How do you ask a model for sharding?
Shard (table) by (tenant or user id), not by a random key. Queries for one tenant hit one shard. Do not start with shards if one database still fits. No cross-shard transaction in this slice.
What goes wrong with sharding?
A shard per customer when most customers are tiny and one is huge. The huge one is still a hot shard. You needed a different split, or a whale on its own node.