NVMe is not a marketing word

Every host advertises NVMe. Fewer explain what it changes. For most small workloads, the honest answer is: it removes disk latency as the first bottleneck, then exposes the next one.

What NVMe changes

A local NVMe device handles many more concurrent I/O operations than a network-attached volume or a spinning disk. For a small PostgreSQL instance, that shows up as lower commit latency and fewer stalls during checkpointing. For a web server, it shows up as faster cold reads and quicker deploys.

It does not make a bad query fast. It does not replace an index. It does not fix a memory leak. It removes one queue and lets you see the next one.

Where the bottleneck moves

Once storage stops stalling, the usual suspects are CPU contention, memory pressure and network round trips. That is why we pair NVMe with dedicated vCPU rather than burstable shares: a fast disk behind a throttled CPU is a sports car on a dirt road.

What we measure

We track p50 and p99 storage latency per host, not just throughput. Throughput numbers look great in a benchmark and mean little when one tenant is stuck behind a queue. If p99 latency drifts, we investigate before it becomes a support ticket.

The practical advice

• Put the database on local NVMe and keep the working set in memory.
• Measure p99, not average. Averages hide the requests your users complain about.
• Take a snapshot before schema changes. It is cheaper than a rollback script.
• If the disk is no longer the bottleneck, stop buying bigger disks and look at the query plan.