A database is bound by whatever its data access stresses: if the hot set fits in memory it's CPU- or network-bound; if data far exceeds memory, random query I/O makes the **disk** the limit (random I/O is slow because the platter must seek). The sharp Flickr finding: the right *metric* mattered as much as the right resource. Disk **utilization** repeatedly hit 100% with no ill effect — but MySQL replication lag only appeared once disk **I/O wait** crossed ~40%. So the ceiling was set at 40% I/O wait, not at any utilization figure. Utilization said "busy"; I/O wait said "starved." This is the same lesson as burstable CPU: a high-looking gauge (or a maxed one) can be benign, while a different, less obvious metric is the true saturation signal. Validate which metric actually predicts user-visible failure (here, lag → stale reads), then make *that* the red line. --- *Source: [[The Art of Capacity Planning]] (John Allspaw, O'Reilly 2008) — Ch 3 — Measurement: Units of Capacity*