Every hosting quote now says NVMe somewhere on the page. Almost none of them say which specification of NVMe, and the two headline numbers, IOPS and sequential throughput, describe different jobs. Buying on the wrong one wastes money. Buying on neither, just on the word NVMe, wastes more. Here is what each number measures, which workloads care about which, and how to test your actual access pattern before you sign.
Sequential throughput is how fast the drive moves one large contiguous stream. Copying a 40 GB backup file, streaming video, reading a big tarball: all throughput jobs. A modern datacentre NVMe drive does 3 to 7 GB per second at the interface, and real-world large-file reads land in the same region once the queue depth is high enough.
IOPS is how many separate read and write operations the drive completes per second, at some small block size, usually 4 KB. This is the database number. A page read from MySQL or PostgreSQL is a random 16 KB or 4 KB operation somewhere on the drive, then another one somewhere else, thousands of times a second. The drive spends its time seeking, queueing and acknowledging, never streaming.
The two can differ by an order of magnitude on the same drive. And neither is the whole story, because latency, the time per operation, decides how long each query waits.
A database doing a point lookup touches a handful of pages. Say 60 random 4 KB reads per query, each taking 100 microseconds of drive time. That's 6 milliseconds of storage latency per query, before the CPU does anything. Now the same drive with a p99 read latency of 200 microseconds under load: the same query's storage bill is 12 ms at the tail, and your p99 page time roughly doubles from a storage detail that never appeared in the quote.
Scale it up. A busy application doing 8,000 random reads per second needs a drive rated well above 8,000 IOPS at 4 KB with a queue depth that can actually deliver it. The marketing number on a consumer NVMe drive, often quoted at queue depth 32 with eight parallel threads, describes a load pattern your database will never produce. Enterprise drives quote lower IOPS at lower queue depths and deliver more of them under mixed read-write load, which is the pattern databases actually generate.
Databases also write constantly: WAL, binlog, checkpointing, temp files. A drive rated at 600 TBW over five years sounds enormous until you count a write-heavy workload doing 200 MB per second of sustained writes, which is about 8.5 TB a day and roughly 15 PB a five-year period. Nobody hits the marketing figure exactly, but the ratio between quoted endurance and plausible write volume is a real filter between consumer and enterprise NVMe. Datacentre-grade drives with power-loss protection also let the database trust its flush calls, which matters for how fsync behaves and how fast commits return.
Mixed load is the part specs hide. A drive that does 100,000 read IOPS and 100,000 write IOPS separately will do fewer than 100,000 combined at a 70/30 mix, sometimes far fewer, because reads and writes contend for the same flash channels and the controller interleaves them. Ask a provider for a fio result at a 70/30 read/write mix, 4 KB blocks, queue depth 8. That single test describes most database servers better than any figure on a datasheet.
One more working rule from the racks: RAM beats NVMe for read caching, and NVMe beats network storage for everything. A database with a 95 percent page cache hit rate asks the drive for almost nothing. Before paying for a faster drive, check the buffer pool size and the hit rate; a 16 GB RAM increase often removes more latency than a drive upgrade that costs three times more.
Run fio on the current server for ten minutes, three tests: sequential read at 1 MB blocks, random read at 4 KB queue depth 8, and a 70/30 mixed run. Record the IOPS, the bandwidth and, most importantly, the p99 latency from each. That gives you the shape of your workload in three numbers, and you can compare a provider's quoted figures against the ones you actually need instead of the ones that print well.
When you evaluate a host, ask for the same fio outputs on their hardware. A provider that can't produce them is either reselling and doesn't know, or knows and won't say. Both are answers. The rest of what a hosting proposal should state up front is covered in our SLA writeup, and if the whole stack, not just the drive, is what's slow, start with where page latency actually comes from.
Mail admin@servercabin.com your fio numbers and we'll tell you whether your workload needs the fast drive or the cheap one. Sometimes the honest answer is the cheap one.