Eleven rungs, cheapest first. Climb only when one runs out.
Each rung buys capacity at a price, and the price rises as you climb. Measurements pick the next one.
30%→90%
CPU in a year at 3× growth
Latency turns unpredictable well before saturation, and a migration takes months. Figma acted when its primary passed 65% at peak.
Slow reads. Cache first?
Bad: Cache it
Hides a missing index until it goes cold, then the full scan arrives thousands of times at once.
Good: Index first
Usually the biggest win per hour, no new parts.
Three replicas or three shards. Which divides the writes?
Every replica still applies all W writes. Only shards split them, and queries without the key hit all three.
Writes stay heavy, and some reads can’t tolerate replica lag. Shard next?
The underrated rung
Split by domain. Figma moved groups of tables always used together onto their own databases, a whole primary each.
1
primary behind ChatGPT’s 800 million users
Plus nearly 50 read replicas, at millions of queries a second. Shardable, write-heavy workloads moved to sharded systems instead.
Four ways to climb wrong
- Sharding early: shard-key tax on every query
- Scaling up a hot row: cores don’t help
- 20 → 200 pods: ten times the connections
- Climbing late: no headroom left to migrate
Remember
Measure what saturates, then climb cheapest first. Copies scale reads; only splitting data scales writes. Split by domain before you shard, and start each move with headroom left.