NVMe vs SSD vs HDD on a VPS: what actually differs, and how to test yours

A plan's pricing page almost always sums up its storage in one word: SSD, NVMe, sometimes just "fast disk." Behind that word could be a local drive plugged into the same physical box as your VM, or network-attached storage that your VPS reaches over the same network as dozens of other tenants. The gap between NVMe and SSD is real, but it doesn't show up everywhere: a static site won't reveal it at all, while a busy database lives or dies by it. Here's what actually differs between the three, and how a couple of fio commands tell you what your own server delivers instead of what the spec sheet promises.

Short version. NVMe and SSD differ from HDD fundamentally: a mechanical drive has a head that physically moves across a platter, and that adds milliseconds to every operation. NVMe differs from SATA SSD in interface and parallelism: the same flash memory underneath, but several times the IOPS and an order of magnitude lower latency under random load, which is databases, lots of small files, dozens of concurrent connections. On sequential reads of one big file, or on a lightweight site, the difference is barely visible. The word "NVMe" on a plan doesn't guarantee you those numbers: the disk behind it might be network-attached and shared across tenants. The only way to know the truth about your own server is to run fio and look at real IOPS and latency, not the marketing copy.

What actually differs: IOPS, latency, sequential vs random

A disk isn't described by one "speed" number. It takes a few together.

IOPS (input/output operations per second) counts how many read or write operations a disk completes per second - usually one fixed-size block, say 4 kilobytes, not a whole file. Latency is the time between requesting one such operation and getting an answer: milliseconds for a spinning HDD, microseconds (thousandths of a millisecond) for SSD and NVMe.

Sequential workloads read or write blocks that sit right next to each other, like copying one large file or running a backup. Random workloads hit scattered, unrelated locations on the disk: that's what a database with thousands of small rows looks like, or a site serving up a pile of small cached files in parallel.

On a mechanical drive, random access almost always runs into the head, which physically has to travel to the right track before it can read or write anything. On SSD and NVMe, data is read electrically with no moving parts, so random access there isn't dramatically slower than sequential - and that's exactly where the gap between drive types shows up hardest.

When it matters, and when it barely does

The useful question isn't "which disk is faster," it's "where would you actually hit its ceiling." It matters for databases under active writes (MySQL, PostgreSQL), for sites with a large number of small files (WordPress caching plugins, heavy asset bundles), for message queues and any service that writes to disk often in small chunks - that's random load, tens of thousands of small operations a second, exactly where a spinning drive or a slow SSD can't keep up. It barely matters for a static site that mostly serves files out of the OS page cache in RAM, for a backup written once a day in one long stream, and for anything where disk was never the bottleneck to begin with: a Telegram bot is far more likely to hit CPU or API rate limits than disk I/O. Paying for NVMe where a SATA SSD would do isn't a mistake exactly, it's just money spent on headroom you won't use, and that adds up on a tight budget.

NVMe vs SSD vs HDD in numbers

The figures below are typical ranges for the drives themselves, pulled from independent storage reviews and vendor documentation as of September 2026. They're not a guarantee for any specific VPS. These are spec-sheet numbers: what a bare drive does in a lab. What your server actually gets through the hypervisor, and possibly over a network, is something only fio can tell you - not this table.

The gap between SATA SSD and NVMe looks dramatic on paper, several times the IOPS, an order of magnitude on latency, but you only run into it if your workload is genuinely random and concurrent. The gap between HDD and any SSD, on the other hand, isn't "a few times," it's hundreds to thousands of times on random access specifically, and that's the one row in this table worth treating as a given without testing it yourself.

How to benchmark the disk on your own VPS: fio

fio (Flexible I/O Tester) is the standard Linux tool for disk benchmarking. It generates controlled load in whatever pattern you specify and reports exact IOPS, throughput, and latency, instead of "I copied a file and eyeballed how long it took."

Install it (it isn't in Ubuntu's base image) and make a scratch directory for the test files so you can clean up in one shot afterward:

sudo apt install fio -y

mkdir -p ~/fiotest && cd ~/fiotest

The first test is sequential write: how fast the disk writes one big file straight through, no jumping around, close to what a backup job or a large file upload looks like.

fio --name=seq-write --filename=testfile --size=1G \

--rw=write --bs=1M --direct=1 --ioengine=libaio \

--numjobs=1 --iodepth=16 --group_reporting

• --direct=1 is the flag that matters most: it routes the write around the OS disk cache. Without it, some of that data effectively lands in RAM instead of on disk, and the result shows you memory speed, not disk speed.
• --bs=1M sets the block size per operation, a typical size for sequential file copying.
• --iodepth=16 is how many operations the disk keeps in flight at once. At a depth of one, a modern NVMe drive never gets close to its rated numbers; it needs a queue to show what it can do.
• --filename matters because the test file needs to sit on the disk you're actually checking, not in /tmp: on some images that's tmpfs, meaning RAM, and the test would measure memory instead. Check the mount with df -T /tmp.

fio prints a lot of running detail, but the only block that actually matters is the summary at the very end. Here's a real result from that exact command, captured on a test server while writing this article (a KVM VPS, Ubuntu 24.04, 2 vCPU, an ordinary virtual disk, not a dedicated NVMe drive):

Run status group 0 (all jobs):

WRITE: bw=839MiB/s (879MB/s), io=1024MiB, run=1221msec

That's one real server's numbers at one point in time, not a benchmark to match or a promise for any VPS - your own server will print different numbers, which is the entire point of running the test yourself.

Reading the same file back is the same command with --rw=read instead of --rw=write, everything else unchanged.

The main event is a mixed random read/write test, which is the closest thing to how a database actually answers queries from several users at once:

fio --name=rand-rw --filename=testfile --size=1G \

--rw=randrw --rwmixread=70 --bs=4k --direct=1 \

--ioengine=libaio --numjobs=4 --iodepth=32 \

--runtime=30 --time_based --group_reporting

On the same test server, this test's summary block looked like this:

Run status group 0 (all jobs):

READ: bw=295MiB/s (310MB/s), io=8856MiB, run=30001msec

WRITE: bw=127MiB/s (133MB/s), io=3805MiB, run=30001msec

Off-screen in that block, fio also logged iops (75.6k on reads, 32.5k on writes) and an average clat latency of about 1.2ms on reads and 1.1ms on writes - at four parallel workers and a queue depth of 32, that's exactly the "single-digit milliseconds under heavy concurrent load" the next section talks about.

• --rw=randrw --rwmixread=70 mixes 70% reads with 30% writes scattered across the file, closer to a real database's traffic than pure reads or pure writes.
• --bs=4k uses a 4-kilobyte block, the standard page size for most databases and file systems, which is why IOPS gets measured on this block size rather than megabyte-sized ones.
• --numjobs=4 runs four parallel workers hitting the disk at once, simulating several concurrent connections instead of a single stream of requests.
• --runtime=30 --time_based runs the test for exactly 30 seconds instead of stopping once a fixed amount of data is written, so you get an averaged result rather than one lucky (or unlucky) moment.

Clean up afterward, the test file takes up a full gigabyte:

cd ~ && rm -rf ~/fiotest

Reading the results: what's normal, what's a red flag

In the summary block, watch three numbers: bw (bandwidth, in MB/s), iops, and average latency clat (completion latency). For the random 4K test these are the main result; for the sequential test, bw matters more.

• Normal: average latency on SSD or NVMe sits in tenths of a millisecond, climbing to single-digit milliseconds under heavy concurrent load. Random IOPS run noticeably higher than the HDD row in the table above, usually by an order of magnitude.
• Red flag: average latency on a disk billed as SSD or NVMe regularly climbing into the tens of milliseconds, which is HDD territory. Either the disk is overloaded by other tenants, or what you're getting isn't what the plan describes.
• The one that's easy to miss: fio also prints percentiles, 99th, 99.9th, alongside the average. If the average looks fine but the 99th percentile is several times higher, that's not overall slowness, it's intermittent stalls: someone else sharing the same storage is periodically grabbing all the throughput. That's what a "noisy neighbor" looks like in practice, even when a provider's own average numbers check out.

Why "NVMe" on the plan doesn't guarantee those numbers

The drive type listed on a plan is what's physically sitting in the provider's rack. It says nothing about how that drive actually reaches you.

Local disk sits physically in the same box as the hypervisor running your VM: a short path through the PCIe bus and a virtual disk driver. Network-attached storage (distributed systems like Ceph and similar) sits physically on other machines, and your VPS reaches it over the provider's internal network. Even with the fastest NVMe drives on the other end, disk latency now stacks on top of network latency plus the overhead of a software layer serving that storage to many tenants at once. Two plans labeled "NVMe" can sit on completely different storage architectures, and from the outside the only way to tell is to measure it, not to read the label.

The second factor is oversubscription: a provider sells the same disk's capacity and speed to multiple customers at once, betting that not everyone hits the ceiling simultaneously. One neighbor running a sloppy backup script can temporarily tank IOPS for everyone sharing that same physical drive or array. That's ordinary hosting economics, not a scam, but it's exactly why the same line item on a plan delivers different numbers from provider to provider, and even from the same provider at different times of day.

What to check before buying, and what to do if your disk is already the problem

Before buying a plan, check whether the disk type is specified for the exact line and location you're ordering; it sometimes differs between a provider's regular plans and a "maximum performance" tier on the same site. If your plan comes with a trial period, spend part of it not just confirming the site loads, but running fio for real, before your own data and traffic land on the box.

If a server is already running and you suspect the disk, don't start with fio, start smaller. The wa column in vmstat 1 5 (covered in the CPU/RAM sizing article) shows the share of time the CPU spends idle waiting on disk; a value that stays high is your first reason to look at storage specifically. Then get a sharper picture with sysstat:

sudo apt install sysstat -y

iostat -x 1 5

The %util column shows how busy the disk is over the interval. For latency, current versions of sysstat (verified on Ubuntu 24.04, package 12.6.1) don't print a single combined await column - iostat -x splits it into r_await and w_await, read and write latency in milliseconds as seen by the application; older sysstat builds (closer to what Ubuntu 22.04 likely ships) still show a combined await alongside the split columns, so check what your own server's command actually prints rather than assuming a specific column name. If %util and the await columns both stay high exactly when the site or database slows down, that's grounds to run fio in a targeted way, to confirm the diagnosis rather than guess at one. Do this during a low-traffic window: fio itself generates extra load and can slow down whatever's already running.

If your server runs OpenVZ or a similar container-based setup instead of KVM, disk and memory readings can be less clear-cut for reasons covered in KVM vs OpenVZ, which also explains why the overall noisy-neighbor risk runs higher on container virtualization, not just for storage.

FAQ

What's the difference between NVMe and SSD on a VPS?

Both are solid-state drives with no moving parts, but NVMe uses a faster interface and handles far more parallel operations at once. The difference shows up under random, highly concurrent load, a busy database, lots of small files. On a light site or a sequential read of one large file, it's not noticeable.

What are IOPS and latency in simple terms?

IOPS counts how many read or write operations a disk finishes per second. Latency is how long you wait for one such operation to complete. High IOPS and low latency together mean a disk handles many small requests quickly at once, which matters a lot for databases and barely at all for a static site.

How do you test disk speed on a VPS with fio?

Install it with sudo apt install fio -y, run a sequential write and read test with --direct=1 so you're measuring the disk instead of the cache, then run a mixed random read/write test with 4-kilobyte blocks and several parallel workers, which is the closest simulation of a real database. The bw, iops, and average latency in the final summary answer what your disk actually delivers.

Do you need NVMe for a regular website or blog?

Usually not. A small site serves most files out of the OS page cache in RAM rather than reading from disk directly, so disk is the last thing it hits a ceiling on. NVMe starts to matter once a database is doing real work on the box, traffic gets genuinely concurrent, or a service writes randomly and heavily.

Why can a VPS disk perform worse than the plan advertises?

Two reasons: "NVMe" on the label can mean network-attached storage, where network latency stacks on top of the drive's own speed, and oversubscription, where several customers share one physical drive and a busy neighbor temporarily eats into your share. The only way to see the real picture is measuring it yourself with fio, not reading the plan description.

What is network-attached storage and how does it differ from local NVMe?

Local NVMe sits physically in the same server running your VM, so the path to your data is short. Network-attached storage sits on other machines in the provider's infrastructure, reached over an internal network, and even with fast drives on the other end, that adds network latency plus dependence on how many other tenants are hitting the same storage at once.

Takeaways

• NVMe and SSD are solid-state with no moving parts; HDD is mechanical and falls behind on random workloads by hundreds to thousands of times, not just "a few times."
• NVMe beats SATA SSD by several times on IOPS and an order of magnitude on latency, but only under random, concurrent load: databases, many small files. On static content and sequential reads, the gap is barely visible.
• fio is the standard tool for an honest measurement; the --direct=1 flag is what makes it test the disk instead of RAM.
• In fio's summary, watch bw, iops, and average latency, and for hidden problems, the 99th percentile: a big gap from the average points at a noisy neighbor even when average numbers look fine.
• "NVMe" on a plan doesn't tell you whether it's local or network-attached storage with extra overhead; only measuring your own server tells you that.
• If a server is already slow, start with the wa column in vmstat 1 5 and iostat -x 1 5, then move to a targeted fio test.

What's next

The full sizing walkthrough, including disk, CPU, and RAM, lives in the pillar article how to choose a VPS. If you're not sure whether CPU and RAM are enough, not just disk, see how much CPU and RAM a server needs. And for how virtualization type affects noisy-neighbor risk and resource predictability more broadly, there's KVM vs OpenVZ.