Database ceilings are trickier than web-server ceilings because hidden cliffs lurk in edge cases that only certain data shapes trigger. Flickr assumed a given platform sustained X queries-per-second before degrading — then found some queries ran fine for a user with under 10,000 photos but slowed alarmingly for one with over 100,000. They had to redefine the ceiling specifically for the server handling large-photo-count users. The lesson: measure with **real data and real queries**, not averages or synthetic loads — the cliff hides in the tail of the data distribution, not the mean. A second mover: schema and query design affect database performance more than hardware speed. Optimizing a few common or expensive queries can change the ceiling dramatically — one day you think you need 10 servers for 20,000 QPS, the next only 5. So a DB ceiling is not a fixed property; re-measure it after any schema, query, or hardware change. --- *Source: [[The Art of Capacity Planning]] (John Allspaw, O'Reilly 2008) — Ch 3 — Measurement: Units of Capacity*