Block size and IOPS: the disk's price list underneath everything
The unit. Disks never move data byte by byte: the unit of one IO operation is a block. In benchmark tools (fio, dd) the knob is literally called bs, and its iconic value is 4KB — a "4K random read/write" benchmark is 4KB blocks thrown at the disk one at a time. The same 4KB shows up everywhere once you look: modern disk sectors are 4KB (Advanced Format), filesystem blocks default to 4KB, and the hardware/OS memory page is 4KB — the block the memory system moves along the bus between components.
The one equation.
On any given disk, small blocks (4K) make the operation count the ceiling — IOPS-bound, bandwidth starved; large blocks (128K, 1MB) let few operations carry full bandwidth. This is the entire tuning grammar: bulk/ETL work (sequential, voluminous) raises the block and buffer sizes to eat bandwidth; point-lookup work lives under the random-IOPS ceiling no matter what it wants.
Interface 1 — the database page is the database's own block size. PostgreSQL chose 8KB, InnoDB 16KB. Too small, and one logical read costs more physical IOs; too large, and changing one byte moves a whole page (read/write amplification) while big pages waste buffer cache. Every page-size debate is a block-size debate.
Interface 2 — a b-tree lookup is priced in random IOPS. A lookup costs 3–4 page reads; each buffer-pool miss is one random physical IO. A spinning disk delivers roughly 100–200 random IOPS — a point lookup budgets in milliseconds; an SSD delivers tens of thousands — microseconds. "The database got ten times faster on SSD" is this number changing. The buffer pool's whole existence is dodging this wall by turning physical IOs into memory hits.
Interface 3 — wal and LSM are the same arbitrage. Sequential large-block IO is priced by bandwidth (abundant); random small IO is priced by IOPS (scarce). WAL converts commit writes from random page flushes into sequential appends; LSM converts random structural writes into sequential file writes. Storage-engine design, at bottom, is arbitrage between these two prices — the hardware layer sets the price list (block size and IOPS), and every structure above it (mvcc's versions, the B-tree, the log) is an optimization against that list.