NVMe VPS vs SSD VPS: Does Storage Speed Really Matter?

Every VPS listing says NVMe now, usually next to a large IOPS number. Whether that changes anything depends on what the server does and how the provider delivers the storage. The hardware background is in NVMe vs SATA SSD vs HDD. This post is narrower: what differs on a VPS specifically, who will notice, and how to test the machine you are paying for.

What actually differs

Both are flash. The difference is the path between the flash and the CPU.

Four terms cover most of it:

• IOPS: operations per second, normally quoted for 4 KB random reads or writes.
• Throughput: megabytes per second, relevant for large sequential files.
• Latency: how long a single operation takes. This is what a database feels.
• Queue depth: how many operations are outstanding at once. A headline IOPS figure is almost always measured at a high queue depth, which a small website never reaches.

At low concurrency the two are closer than the marketing suggests. The gap opens when many things read and write at once.

On a VPS, the drive is only part of the story

Inside a virtual machine you do not see the physical drive. You see a virtual disk:

lsblk -d -o NAME,SIZE,ROTA,MODEL

On a KVM guest this typically shows vda or sda with a generic model name, whatever the hardware underneath. The device name tells you nothing about NVMe, and the ROTA flag is not reliable inside a guest either.

Three things sit between you and the flash:

1. Local or network storage. A virtual disk on NVMe drives inside the host has very low latency. A virtual disk on a storage cluster reached over the network may also be built from NVMe drives, but every operation crosses the network first.
2. Per-VM limits. Many providers cap IOPS or throughput per virtual machine so one customer cannot starve the rest. Your result is then the cap, not the drive.
3. Neighbours. Other machines share the same drives. Results vary by hour.

So "NVMe VPS" tells you what the provider bought. Only a measurement tells you what you get.

Which workloads notice

Databases. Every committed transaction waits for a flush to disk. A busy MySQL, MariaDB or PostgreSQL server with a dataset larger than memory does a stream of small random reads plus synchronous writes, exactly what low latency helps. Before blaming the disk, though, check the buffer pool is sized sensibly: MySQL and MariaDB tuning basics. A database that fits in RAM barely reads from disk at all.

Many small files. Composer and npm installs, Git operations, mail directories with tens of thousands of messages, PHP applications with thousands of files and a cold cache.

Backups and restores. Archiving a site reads everything once, competing with live traffic.

And those that mostly do not:

• Static sites and fully cached pages. After the first request the files are served from the kernel's page cache in RAM.
• CPU-bound applications. If the time is spent in PHP or in a slow external API, storage is not in the path.

Find out whether your workload is waiting on disk

Before benchmarking anything, look at the real workload. Install sysstat and watch during a busy period:

sudo apt install sysstat        # Debian, Ubuntu
sudo dnf install sysstat        # AlmaLinux, Rocky
iostat -x 5

Read three columns for your disk: r_await and w_await are the average milliseconds a read or write waited, and %util is how much of the time the device was busy. In vmstat 5, the wa column is CPU time spent waiting on I/O. If the awaits stay low and wa sits near zero while the site is slow, faster storage will not help and you should look at CPU and memory instead.

Benchmark it properly with fio

fio is in the standard repositories of every current distribution (apt install fio or dnf install fio).

Read this first. These tests create a real file of the size you specify and write to it hard. Check free space with df -h, run them outside peak hours and keep them short, because heavy benchmarking also slows other customers on the same host. Always point --filename at a file path. Pointing it at a device such as /dev/vda in a write test destroys the data on that device.

Random 4 KB reads at a high queue depth, the number vendors quote:

fio --name=randread --filename=/root/fio.test --size=2G \
    --rw=randread --bs=4k --ioengine=libaio --direct=1 \
    --iodepth=32 --numjobs=1 --runtime=60 --time_based --group_reporting

A mixed read and write load, closer to a database:

fio --name=mixed --filename=/root/fio.test --size=2G \
    --rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --direct=1 \
    --iodepth=16 --numjobs=1 --runtime=60 --time_based --group_reporting

Synchronous small writes, which is what a transaction commit looks like:

fio --name=commit --filename=/root/fio.test --size=256M \
    --rw=write --bs=4k --ioengine=sync --fdatasync=1 \
    --runtime=30 --time_based

Then delete the file: rm /root/fio.test.

--direct=1 bypasses the page cache. Leave it out and you benchmark your RAM, which produces spectacular numbers that mean nothing.

How to read the output

The result block looks like this in shape, with your own values:

read: IOPS=..., BW=...MiB/s
    clat (usec): min=..., max=..., avg=..., stdev=...
    clat percentiles (usec):
     | 50.00th=[...], 95.00th=[...], 99.00th=[...], 99.90th=[...]

• IOPS and BW are the averages for the run.
• clat is completion latency per operation. The average is the least interesting figure.
• The percentiles matter most. The 99th percentile is what the slowest one request in a hundred experienced. A high average IOPS with a 99th percentile many times the median means inconsistent storage, and a database will feel the bad moments.
• In the commit test, read the fsync/fdatasync latency block. That is the time each commit would wait.

Tip: run each test three times, at different times of day, and compare. On shared storage a single run is an anecdote. If results swing widely between runs, the variance is the finding.

Tip: if IOPS lands on a suspiciously round number and stays there however you change the queue depth, you have found the provider's per-VM cap.

A quick latency check with ioping

ioping does for disks what ping does for networks. It is in the Debian and Ubuntu repositories, and in EPEL on AlmaLinux and Rocky.

ioping -c 20 /var/lib/mysql

It issues one small read at a time against the directory you name and prints a min/avg/max/mdev line. The test is non-destructive. Watch max and mdev as much as avg: a low average with occasional long outliers is the signature of contention.

Why vendor numbers never match yours

A published number depends on block size, read or write, queue depth and job count, test length (some drives are fast in short bursts and slower when sustained), whether the cache was bypassed, and whether the host was empty when it was measured. A drive manufacturer's figure is for a bare drive, not a virtual disk behind a hypervisor, a RAID layer and a rate limit. Compare providers only with the same command run by you.

So, does it matter

For a database-backed application with real concurrency, yes, and latency consistency matters more than peak IOPS. For a cached site with modest traffic, RAM and CPU decide more than the storage type. Our Cloud VPS plans use NVMe storage, and the commands above work on those as on any other server. If you are still deciding whether you need a VPS at all, start with shared hosting or VPS.