A datasheet compares megabytes per second, and a web server almost never reads a large file end to end. It reads thousands of small pieces at once - rows, index pages, session files - and that is a different measurement entirely.

The number that matters

  • A spinning disk - a few hundred operations a second, because a physical arm has to move.
  • A SATA SSD - tens of thousands, limited by an interface designed for spinning disks.
  • NVMe - hundreds of thousands, talking to the processor directly with many queues at once.

The queue depth is the real difference: SATA has one queue of 32; NVMe has thousands of queues, thousands deep. Twenty PHP workers all asking for something at the same moment is exactly that shape.

Where you feel it

  • A database doing many small reads - almost every page of a CMS.
  • Sessions and caches written as files.
  • A backup, an import, or a large delete, where the whole job is small operations.

Where you do not

If the working set fits in memory, the disk is barely touched and NVMe changes very little. Buying faster storage when the answer is more RAM is a common and expensive mistake.

Measure your own

fio --name=rand --rw=randread --bs=4k --size=1G --numjobs=4 --iodepth=32 --runtime=30 --time_based --group_reporting

That measures small random reads at depth, which is the pattern a database produces. Sequential benchmarks measure something your server never does.

Check the iowait first: top, the %wa figure. Near zero means storage is not your bottleneck, whatever the disk is.