NVMe VPS performance benchmarks: what actually matters

Every VPS page says NVMe. Sequential fill of a 4 GB file tells you almost nothing about how that disk behaves when PostgreSQL, a container image pull and a backup run at once. The spread between vendors is not “some are 10 % faster.” It is local PCIe versus a shared pool with a courtesy burst.

Numbers that change a design

Ignore peak MB/s from a vendor slide. Collect, on a quiet and a busy hour:

• Random 4K IOPS read and write, queue depth 1 and 32.
• p50 / p99 latency for the same. A pretty average with a 20 ms tail will stall commits.
• Fsync / `fdatasync` time. Databases live here.
• Sustained figures after the first minute, not the first five seconds of cache.

If the provider cannot tell you whether the namespace is dedicated to the hypervisor or carved from a multi-tenant array, treat the SKU as unknown.

What we run

Public cloud instances at Zenix sit on dedicated NVMe arrays presented through KVM. There is no spinning-disk fallback and no SAN in the guest path. Plan sizes and included transfer are in the catalogue; we do not publish a synthetic “1 000 000 IOPS” badge because that number is meaningless without queue depth, block size and isolation.

Dedicated metal with local NVMe still wins when the working set is large and you need the entire drive. Cloud wins when you want the same NVMe class in a smaller increment and a same-day rebuild. See the dedicated comparison if the guest is becoming a database host.

How to test a candidate

1. Provision the SKU you will actually buy, not the demo.
2. Disable the vendor agent that “optimises” first-write.
3. Run a mixed fio job for at least fifteen minutes.
4. Repeat during their backup window if you can learn it.
5. Keep the raw logs. Marketing will not.

A VPS that is honest about local vs pooled and shows p99 will beat a prettier sequential chart. That is the only comparison we recommend to customers who ask “is your NVMe real.”