NVMe vs SSD and HDD: how the disk affects website speed and how to measure it

In plan descriptions, the disk is usually mentioned in a single line — "NVMe" or "SSD" — and it is easy to overlook while looking at the number of cores. In practice, it is the disk that most often determines how quickly the admin panel opens, how fast a catalog export runs, and whether the site can survive a traffic spike.

Let us break down how these disk types actually differ, where the difference is visible to the naked eye, where it can be ignored, and how to measure disk speed on your server with a few commands.

Three types of disks in three paragraphs

HDD is a mechanical disk with spinning platters and a moving read head. To read data, the head has to physically travel to the right location, which takes milliseconds. It is still adequate for sequential reading of large files and is inexpensive, but on many small operations — which is exactly what a database does — it falls hopelessly behind.

SSD consists of memory chips with no moving parts, connected via the SATA interface. Latency drops by roughly a factor of one hundred, but the interface itself hits a ceiling of around 550 MB/s — it was originally designed for mechanical drives.

NVMe uses the same memory chips but connects directly to the PCI Express bus, bypassing the outdated interface. This is what delivers speeds of several gigabytes per second and, more importantly, the ability to handle tens of thousands of parallel requests instead of a single queue.

The numbers that matter

Comparing disks by gigabytes per second is the most common mistake. For a website, two other characteristics matter more: IOPS (how many small operations per second the disk can handle) and response latency.

As a rough guide: an HDD delivers 100 to 200 IOPS with latency in the single-digit millisecond range; a SATA SSD delivers around 50,000 to 90,000 IOPS with latency of about 0.1 ms; NVMe delivers hundreds of thousands of IOPS with latency in the tens of microseconds. The difference between HDD and SSD is measured in hundreds of times; between SSD and NVMe it averages three to ten times.

Translating this into website terms is straightforward: a page on an online store with filters makes dozens of database queries, and each one waits for the disk. As the queue of requests grows, the latency difference is multiplied by their number — this is how "the site feels a bit slow" turns into "the page takes six seconds to load".

Where the difference is noticeable and where it is not

Most noticeably: database operations, the WordPress and Bitrix admin panels, unpacking and installing packages, building projects, importing and exporting catalogs, restoring from a backup, starting Docker containers.

Barely noticeable: serving static pages and images (these are cached by memory and the browser anyway), a VPN tunnel, a simple Telegram bot, video delivery — the bottleneck there is the network, not the disk.

In other words, for a VPN or a bot there is no point in paying extra for the fastest disk. But for a site with a database, it is the first thing to look at after the amount of RAM.

How to measure disk speed on your server

You can verify what you actually got in five minutes. If you do not have a server yet: in the NodexGo panel click "Create server", choose a location (your real ping is shown next to each one), a plan, the Ubuntu 24.04 image, and a billing period — 1, 3, 6, or 12 months. The IP address and root password will appear in the panel and be sent to your email, after which you connect:

ssh root@server-IP-address

Install a tool for an honest benchmark. The fio utility can stress the disk exactly the way a database does — with small random operations:

apt update && apt install -y fio

First test — sequential read, the "gigabytes per second" figure you see in marketing:

fio --name=seqread --rw=read --bs=1M --size=1G --numjobs=1 --runtime=30 --time_based --group_reporting --filename=/root/fiotest

Second test — what actually happens on a production server: random operations with 4 KB blocks across 16 threads. This is the number that determines website speed:

fio --name=randrw --rw=randrw --rwmixread=70 --bs=4k --iodepth=16 --size=1G --numjobs=4 --runtime=30 --time_based --group_reporting --filename=/root/fiotest

In the output, look at the IOPS line and the latency lat (avg). For NVMe, tens of thousands of IOPS and latency in the hundreds of microseconds are normal. If you see hundreds of IOPS and milliseconds, you are on a mechanical disk or a heavily overloaded storage system.

After the test, remove the file — it takes up one gigabyte:

rm -f /root/fiotest

How to tell if the disk is the bottleneck

On a running server, the easiest approach is to look at the load per device. Install the utilities and start monitoring:

apt install -y sysstat
iostat -x 5 3

The key column is %util. Values near 100% mean the disk is busy constantly and has become the bottleneck. The adjacent column await shows the average wait time for an operation: for NVMe this is a fraction of a millisecond.

Another reliable sign is processes stuck in an I/O wait state. You can check them like this:

top -bn1 | head -3

In the %Cpu line, look at the wa (iowait) value: a sustained 20 to 30 percent means the CPU is sitting idle waiting for the disk.

How to get the most out of NVMe

A fast disk can easily be undermined by incorrect settings. First: the ext4 filesystem records the last access time for every file by default — these are unnecessary writes for no reason. This is disabled with a single parameter in /etc/fstab:

nano /etc/fstab

/dev/vda1  /  ext4  defaults,noatime  0  1

Second: the database should know it has a fast disk underneath it. For MySQL and MariaDB it makes sense to raise the I/O limit — the default value is calibrated for mechanical drives:

nano /etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld]
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
innodb_flush_neighbors = 0

systemctl restart mysql

Third: keep an eye on free space. A drive that is 95% full loses speed and can bring down the database — check regularly:

df -h

What matters more than the disk

An honest priority order when choosing a server looks like this: first, RAM must be sufficient (a shortage kills processes and negates any disk speed), then you need a fast disk, and only after that — additional cores. The CPU hits its ceiling least often in web projects.

And remember: the fastest disk will not save a site that lacks caching and has heavy database queries. Optimization usually delivers a bigger gain than changing hardware — but starting with a knowingly slow disk is still not a good idea, because you will hit its limits very quickly.

In brief

Today an HDD is only suitable for storing archives and backups. A SATA SSD is a workable option for a site without a large database. NVMe is what you need for a store, an admin panel, a database, and containers: the difference is felt on the very first day of working in the admin area.

You can check your server with the fio and iostat commands from this article. If it turns out that the bottleneck is RAM rather than the disk, the server card in the panel has an "Upgrade" button: the plan is switched to a higher tier, the disk and IP address are preserved, and nothing needs to be reinstalled.