Disk speed matters when your database queries start backing up or your WordPress media library takes thirty seconds to load in the admin panel. Marketing pages love to print "NVMe" in bold letters, but actual IOPS under load tells you whether that upgrade is real or just a faster controller in front of the same tired spindle array.
I ran fio benchmarks against five popular NVMe-backed VPS providers to measure random 4K read/write IOPS, sequential throughput, and latency under concurrent load. The goal was simple: find out which hosts deliver consistent disk performance when you need it, not just in synthetic single-threaded tests.
Why NVMe matters for VPS workloads
NVMe drives connect over PCIe lanes instead of SATA. That architectural shift cuts protocol overhead and lets the drive handle tens of thousands of I/O operations in parallel. For a web application that writes session data, logs requests, and queries a database simultaneously, parallel queue depth is the difference between sub-millisecond response times and users staring at spinners.
Traditional SATA SSDs top out around 500 MB/s sequential reads and maybe 90,000 IOPS under ideal lab conditions. Real VPS workloads see far less because hypervisor I/O scheduling and noisy neighbors fragment those numbers. NVMe drives start at 1,500 MB/s sequential and can sustain 200,000+ IOPS when the virtualization layer is tuned correctly.
But the label "NVMe" guarantees nothing. I've seen hosts advertise NVMe storage while running KVM with outdated virtio-blk drivers that bottleneck at SATA-like speeds. The only way to know is to test.
The benchmark methodology
Each test ran on a fresh 4 GB RAM VPS instance with two vCPUs, Ubuntu 22.04, and a 50 GB NVMe volume. I used fio version 3.33 with the following test suite:
# Random 4K read IOPS (queue depth 32, 60s)
fio --name=rand_read --ioengine=libaio --rw=randread --bs=4k \
--numjobs=4 --iodepth=32 --runtime=60 --time_based \
--filename=/mnt/test --size=4G --direct=1 --group_reporting
# Random 4K write IOPS (queue depth 32, 60s)
fio --name=rand_write --ioengine=libaio --rw=randwrite --bs=4k \
--numjobs=4 --iodepth=32 --runtime=60 --time_based \
--filename=/mnt/test --size=4G --direct=1 --group_reporting
# Sequential 1M read throughput
fio --name=seq_read --ioengine=libaio --rw=read --bs=1m \
--numjobs=1 --iodepth=8 --runtime=30 --time_based \
--filename=/mnt/test --size=4G --direct=1 --group_reporting
# Sequential 1M write throughput
fio --name=seq_write --ioengine=libaio --rw=write --bs=1m \
--numjobs=1 --iodepth=8 --runtime=30 --time_based \
--filename=/mnt/test --size=4G --direct=1 --group_reporting
Direct I/O (--direct=1) bypasses kernel page cache to measure actual disk performance. Queue depth 32 simulates realistic concurrency from a moderately busy web app. I ran each test three times and averaged the results to smooth out hypervisor scheduling noise.
Latency measurements used the 99th percentile values from fio's output because mean latency hides the tail events that make users click the back button.
Provider one: DigitalOcean Droplets
DigitalOcean's Premium AMD and Premium Intel droplets both advertise NVMe local storage. The $24/month 4 GB instance delivered solid mid-range numbers:
- Random 4K read: approximately 40,000 IOPS
- Random 4K write: approximately 25,000 IOPS
- Sequential read: around 1,200 MB/s
- Sequential write: around 900 MB/s
- 99th percentile read latency: under 4 ms
Performance stayed consistent across multiple test runs. No wild swings in latency or sudden IOPS drops. The virtio-scsi driver was properly configured and queue depth scaled linearly up to 64.
One note: DigitalOcean's block storage volumes are separate from the local NVMe boot disk. If you attach a block volume for database storage, expect lower IOPS because those volumes run on a shared SAN cluster.
Provider two: Vultr High Frequency Compute
Vultr's High Frequency line uses NVMe with dedicated CPU cores. The 4 GB plan at around $24/month showed strong sequential reads but slightly lower random write IOPS:
- Random 4K read: approximately 50,000 IOPS
- Random 4K write: approximately 20,000 IOPS
- Sequential read: around 1,500 MB/s
- Sequential write: around 800 MB/s
- 99th percentile read latency: under 3 ms
Random write IOPS lagged behind the other providers. During the 60-second write test, IOPS dipped noticeably after the first 30 seconds, suggesting either write cache exhaustion or I/O throttling kicking in.
Sequential reads were the fastest in this test group. If your workload is read-heavy (caching layers, static site generation, media serving), Vultr's setup handles it well.
Provider three: Linode (Akamai)
Linode rebranded under Akamai but kept the same NVMe-backed shared CPU instances. The 4 GB plan ran about $24/month and produced balanced results:
- Random 4K read: approximately 45,000 IOPS
- Random 4K write: approximately 30,000 IOPS
- Sequential read: around 1,300 MB/s
- Sequential write: around 950 MB/s
- 99th percentile read latency: under 3.5 ms
Write performance held steady across all three test runs with no obvious throttling. Latency distribution was tight—95th percentile and 99th percentile values stayed within 1 ms of each other, which means fewer outlier spikes.
Linode's KVM setup uses virtio-blk with io_uring support on newer kernels, and you can see it in the latency numbers. If you're running a write-heavy app (logging pipeline, time-series database), this consistency matters more than peak IOPS.
Provider four: Hetzner Cloud
Hetzner's European data centers offer CPX instances with NVMe local storage at lower prices than US-based competitors. A 4 GB CPX21 instance costs around €8/month and delivered:
- Random 4K read: approximately 35,000 IOPS
- Random 4K write: approximately 28,000 IOPS
- Sequential read: around 1,100 MB/s
- Sequential write: around 850 MB/s
- 99th percentile read latency: under 5 ms
Performance per dollar is excellent. Random write IOPS were slightly below the US providers, but sequential throughput stayed competitive. Latency was the highest in this group—not bad by any measure, but noticeable if you're comparing tail latencies side by side.
One thing to watch: Hetzner's network traffic is metered after the first terabyte. If you're moving a lot of data, factor that into your monthly cost.
Provider five: OVHcloud
OVHcloud's VPS line recently moved to NVMe storage across all tiers. Their 4 GB instance ran about $20/month and showed:
- Random 4K read: approximately 38,000 IOPS
- Random 4K write: approximately 22,000 IOPS
- Sequential read: around 1,250 MB/s
- Sequential write: around 750 MB/s
- 99th percentile read latency: under 4.5 ms
Sequential write speeds were the lowest in this test set. During the write throughput test, fio reported intermittent stalls where IOPS dropped to zero for 200-300 ms before recovering. That pattern suggests either hypervisor I/O scheduling contention or shared storage backend congestion.
Random read performance was solid and consistent. For read-heavy workloads, OVHcloud's pricing and performance balance out, but write-intensive apps might hit frustrating pauses.
What the numbers mean for your workload
High random read IOPS help with:
- Database queries hitting scattered indexes
- Content management systems loading media thumbnails
- Caching layers reading from disk-backed stores
- Log aggregation tools scanning rotated files
Random write IOPS matter for:
- Session stores committing user state
- Application logs flushing to disk
- Databases processing transactions
- Any workload with
fsync()in the hot path
Sequential throughput becomes the bottleneck when you're:
- Streaming large video files
- Running backups or transferring snapshots
- Processing bulk data imports
- Building Docker images with multi-gigabyte layers
Latency under load determines how your app feels during traffic spikes. A 99th percentile latency of 3 ms means one in every hundred requests waits 3 ms just for disk. If your page makes 50 database calls, that's a 150 ms penalty in the tail.
How to run your own benchmark
Install fio on your VPS:
sudo apt update && sudo apt install -y fio
Create a mount point if you want to test a separate volume:
sudo mkdir /mnt/test
sudo chmod 777 /mnt/test
Run the random 4K read test first:
sudo fio --name=test --ioengine=libaio --rw=randread --bs=4k \
--numjobs=4 --iodepth=32 --runtime=60 --time_based \
--filename=/mnt/test/testfile --size=4G --direct=1 \
--group_reporting --output-format=normal
Pay attention to the "IOPS=" line in the output and the "clat percentiles" section that shows latency distribution. Run the test three times and average the IOPS values. Single runs can be misleading if you catch the hypervisor during a maintenance cycle or heavy neighbor activity.
For sequential throughput, switch --bs=4k to --bs=1m, set --iodepth=8, and change --rw=randread to --rw=read. The BW= line in fio's output shows throughput in MB/s.
Clean up the test file:
sudo rm /mnt/test/testfile
Picking a provider based on your workload
If your app does more reads than writes—caching servers, content delivery, static site hosting—go for the provider with the highest random read IOPS and sequential read throughput. Vultr and Linode both performed well here.
Write-heavy workloads benefit from consistent random write IOPS and tight latency distributions. Linode showed the most stable write performance under sustained load, followed by Hetzner.
For mixed workloads with balanced read/write patterns, DigitalOcean's stable mid-range numbers across all metrics make it a safe pick. No single test stood out, but nothing fell behind either.
Budget-conscious projects running in Europe should test Hetzner. The price-to-performance ratio is hard to beat if you can handle the slightly higher tail latencies.
OVHcloud works for read-dominant workloads on a tight budget, but the write stalls I observed would make me cautious about running a database primary there.
What if the benchmarks look good but production performance is terrible?
A few things to check. First, your application might be using buffered I/O through the kernel page cache, which hides disk latency until memory pressure forces evictions. Profile your app with iostat -x 1 during peak load to see actual disk wait times.
Second, your workload might not be using asynchronous I/O or sufficient queue depth. Single-threaded synchronous reads can't take advantage of NVMe's parallel queue architecture. Switching to io_uring or libaio often unlocks better performance.
Third, filesystem overhead matters. Ext4 with default mount options adds journaling and metadata writes that can cut random write IOPS by 30%. If you're running a database, consider XFS with noatime and nodiratime mount flags, or tune Ext4's journal mode.
Does NVMe help if my database fits in RAM?
Yes, more than you'd think. Even with a fully cached dataset, databases flush transaction logs to disk on every commit. PostgreSQL's WAL writes and MySQL's InnoDB redo logs are sequential, but high transaction rates still benefit from NVMe's low latency.
Checkpoint operations—where the database writes dirty pages from memory to disk—can stall queries if disk throughput is low. NVMe's sequential write speed reduces checkpoint duration, which shrinks the window where locks block other transactions.
Backups and replica synchronization also hit the disk. Fast sequential reads mean faster base backups and quicker catch-up when a replica falls behind.
How do I know if I'm hitting storage limits or CPU limits?
Run top or htop while your app is slow. If CPU usage is below 70% but iostat -x 1 shows high %util on your disk device, storage is the bottleneck. Look at the await column—anything above 10 ms consistently means I/O is backing up.
If CPU is pinned at 100% and %util stays low, you need more compute. Most NVMe VPS plans scale CPU and storage together, so upgrading usually solves both.
Profile your app to see where time is spent. Tools like perf on Linux or built-in profilers in your language runtime will show whether your code is waiting on I/O or burning CPU cycles.
Can I trust marketing claims about NVMe performance?
No. Hosts love to quote bare-metal NVMe drive specs (200,000+ IOPS, 3,000 MB/s throughput) without mentioning that virtualization overhead, shared storage backends, and I/O throttling cut those numbers by 70% or more in a VPS.
Run your own fio tests during the trial period. If the provider offers a money-back window, benchmark first before you migrate production workloads. Some hosts disable I/O limits during trials to game reviews, so test again after a few weeks.
Watch for inconsistent performance across multiple runs. If IOPS swing wildly (30,000 one minute, 10,000 the next), you're probably on a congested hypervisor with poor I/O scheduling.
What to check before you migrate
Make sure your provider's NVMe storage is local to the hypervisor, not a networked SAN with NVMe caching. Local NVMe gives you sub-millisecond latency; SAN-backed volumes add network round-trip time to every I/O operation.
Check if the provider throttles I/O after sustained high usage. Some hosts advertise burst IOPS that only last 15-30 minutes before throttling kicks in. Read the fine print or ask support directly.
Test during peak hours if possible. Benchmarking at 3 AM local time might show great numbers because the hypervisor is idle, but production traffic hits during business hours when neighbors are also active.
Verify that the virtio driver version supports modern features like multiqueue and io_uring. You can check the loaded driver with lsmod | grep virtio and kernel support with uname -r. Kernels older than 5.1 won't have io_uring, which limits NVMe performance on some hosts.
Finally, run a real workload simulation if you can. Synthetic benchmarks like fio are useful for comparison, but your actual app might stress the disk differently. Deploy a staging environment and replay production traffic patterns to see how it holds up.