NVMe or SSD: does it matter for a website
For a small site the difference between NVMe and SSD is barely noticeable, because pages are served from memory rather than from disk. It shows up in shops and sites with a large database. At the same host NVMe costs only about $0.50–1 a month more, and sometimes less, so what usually decides it is not the disk type but its size and how the host has limited it.
If you run a blog, a business-card site or a landing page, visitors will not notice whether the server has NVMe or a regular SSD. A cached page is served from memory in milliseconds, and the disk barely takes part. The difference becomes visible when the site constantly reads from and writes to its database: in an online shop with thousands of products, in catalog search, during price list imports, in the WordPress admin with WooCommerce or in Magento.
So the rule is simple. If NVMe costs the same or slightly more, take NVMe. If you would have to cut memory to get it, take more memory on SSD instead: 2 GB on SSD is more useful for a site than 1 GB on NVMe, because a database that fits in memory hardly touches the disk.
How NVMe differs from SSD
Both are flash storage with no moving parts; the difference is how they connect to the computer. A regular SSD uses the SATA interface, which was originally designed for hard drives. Its ceiling is about 550 MB/s, and it handles a single queue of 32 commands. NVMe is connected directly to the PCIe bus: up to 3.5 GB/s on PCIe 3.0, up to 7 GB/s on PCIe 4.0, and there can be thousands of queues.
What matters for a site is not megabytes per second but the latency of small operations. A database reads and writes chunks of 4–16 KB in random places on the disk, and each visitor request may wait for dozens of such operations. On NVMe each operation takes less time, and under concurrent load the gap widens, because requests do not stand in a single queue.
There is an important caveat on a VPS. You do not get a physical disk but a virtual slice of shared storage, and the host almost always limits its speed so that one customer does not disturb the others. An "NVMe" disk with a tight limit can be slower than a good SSD without one. So the word in the plan is a reason to choose, not a guarantee, and the disk is worth testing on day one. I show how below.
How much more NVMe costs
Hardly any more. I compared plans with the same memory at the same host: I took the cheapest NVMe plan and the cheapest SSD plan and looked at the difference, using the accsly catalog data of 27 October 2026. There were between 88 and 236 such host pairs depending on the memory size. The catalog stores prices in roubles, so the dollar amounts are rounded.
With 2 GB of memory, NVMe at the median costs about half a dollar more per month, around 8%. With 4 and 8 GB, about a dollar more, or 7–10%. Over a year the extra cost is roughly $6–12. Meanwhile, at 40–50% of hosts with 2–8 GB plans, NVMe costs the same as SSD or less. It looks as if many hosts have already moved their main hardware to NVMe, and SSD remains in older product lines that are not always cheaper.
The catch is elsewhere: NVMe plans usually come with less space. With 2 GB of memory the median disk size is 30 GB on NVMe versus 40 GB on SSD, and with 4 GB it is 60 versus 75 GB. For a site with a large media library, or for keeping backups on the server itself, this can tip the choice towards SSD.
NVMe is now found in 40% of the plans in the catalog. Selection: NVMe VPS. If you need cheap space for archives and backups and speed does not matter, there are also hard-drive plans: HDD VPS.
When a site will feel NVMe
Take a WooCommerce shop with 20,000 products and a 3 GB database on a server with 4 GB of memory. The database does not fit entirely in memory, so catalog filters, search and checkout will read from the disk. Here NVMe speeds up the slowest pages, and that is worth the extra dollar. Plans for this kind of work: VPS for an online store.
The second case is heavy writing. By default, every committed change in MySQL or PostgreSQL is flushed to disk with a sync command, and the server waits until the disk confirms the write. A site with active comments, action logging, job queues or sessions stored in the database runs into exactly this. For such projects the VPS for databases selection is worth a look.
For a business-card site or a WordPress blog with page caching, the difference disappears into measurement noise. It is better to spend the money on memory or on a server closer to your visitors: a data centre in Frankfurt or London for a European audience, in New York or Virginia for the US East Coast. Selection: VPS for WordPress.
Which disk you actually got
Inside a virtual machine the type of the physical disk is usually hidden. The command
lsblk -d -o NAME,ROTA,SIZE,MODEL
shows a disk with a name like vda or sda and an empty model. A value of 0 in the ROTA column means the system considers the disk non-rotational, but the host can set this to anything. The name nvme0n1 appears when the host gives the machine a virtual NVMe device, yet even that says nothing about the real speed. Only a test tells the truth.
Testing the disk: fio and how to read the results
The most accurate tool is fio. On Ubuntu and Debian it installs with apt install fio. Run the tests on a fresh server before a live site is on it, because they load the disk. Each test creates a 1 GB file, so make sure there is space.
Test 1. Latency of a single operation. This is closest to what a site experiences:
fio --name=lat --filename=/root/fio.test --size=1G --rw=randread --bs=4k \
--iodepth=1 --direct=1 --ioengine=libaio --runtime=30 --time_based
In the output, find the clat line in the read block and the average value avg in it, then the percentile table below and the 99.00th line. Units are shown in brackets: usec is microseconds, msec is milliseconds. On a good disk the average stays within 100–300 microseconds. If it is around a millisecond or higher and the 99th percentile goes into tens of milliseconds, the disk is overloaded or network-attached, and the database will be slow whatever the plan is called.
Test 2. How many operations the disk sustains under load.
fio --name=iops --filename=/root/fio.test --size=1G --rw=randrw --rwmixread=70 \
--bs=4k --iodepth=32 --direct=1 --ioengine=libaio --runtime=60 --time_based
Look at IOPS= in the read and write lines. A few thousand operations per second is enough for a site or a small shop. If the plan is sold as NVMe but read plus write comes to less than 5,000–10,000, the host has capped the disk. A flat round number, for example exactly 10.0k on every run, also points to a limit.
Test 3. Synchronous write speed. This is how a database writes every committed change:
fio --name=sync --filename=/root/fio.test --size=256M --rw=write --bs=4k \
--ioengine=sync --fsync=1 --runtime=30 --time_based
You need IOPS= in the write line: the number of confirmed writes per second. A thousand or more is good, and the database will write changes without waiting. If you get less than 200, every saved order or comment will wait for the disk.
The --direct=1 flag in the first two tests is essential. Without it fio measures the memory cache, and the result comes out several times too high. After the tests, delete the file: rm /root/fio.test.
A quick check with dd if fio is not available
The dd utility is present on every system. It is cruder but needs no installation. Sequential write:
dd if=/dev/zero of=/root/dd.test bs=1M count=1024 oflag=direct
The last line of the output shows the speed. A regular SATA SSD cannot deliver more than 550 MB/s, so figures above that indicate NVMe or fast storage. Less than 200 MB/s for an "NVMe" plan is a reason to ask the host about limits. But keep in mind that sequential writing hardly matters for a site: it is how large files are copied, not how requests are handled.
Synchronous writes in small blocks, closer to how a database works:
dd if=/dev/zero of=/root/dd.test bs=4k count=2000 oflag=dsync
Divide 2,000 by the number of seconds in the output, and you get how many writes per second the disk sustains. If dd finished in one or two seconds, that is a thousand writes per second or more, and all is well. If it took 10–20 seconds, each write takes 5–10 ms, and the database will feel it. After the check: rm /root/dd.test.
How not to misread the results
Run the tests two or three times at different times of day, for example in the afternoon and late in the evening. If the results jump by a factor of several, the disk is shared with busy neighbours, and the site will be slower at peak hours. Compare servers with the same commands: figures from different tools and different settings cannot be compared with each other.
Do this in the first days, while the refund period is still valid. Plans that offer one are in the money-back VPS selection. Testing the network and the processor is covered in the article how to check VPS speed, and the other plan parameters in how to choose a VPS.