Every third VPS listing now advertises "blazing NVMe storage." Half of them are lying. I've benchmarked dozens of instances over the past two years, and the gap between claimed NVMe and actual block-device latency is often 10x. Marketing departments discovered that "NVMe" converts better than "SSD," so they slap it on shared-SAN storage and hope you won't test it.
This guide walks you through six providers where I've verified real NVMe backing, plus the exact commands I use to audit storage claims. You'll know what to look for in your own tests and why random 4K write IOPS matter more than sequential read marketing screenshots.
What NVMe actually means in VPS hosting
NVMe is a protocol, not a drive type. It replaces SATA/SAS with a PCI Express connection that removes legacy bus overhead. On bare metal you see latency drop from 500 microseconds to 50. On a VPS, those numbers mean the hypervisor is passing through real NVMe block storage, not emulating it over a SAN fabric that connects to spinning rust three hops away.
Most hosts run QEMU/KVM or Xen. When you see /dev/vda or /dev/xvda inside the guest, the hypervisor is presenting a virtual SCSI or paravirtualized block device. That device can be backed by NVMe on the host, but it can also be backed by a Ceph cluster on SATA SSDs over 10GbE. The guest has no way to know without testing.
Why random 4K writes expose the truth
Sequential reads are easy to cache. A provider can put 512GB of RAM in front of a slow SAN and your dd test will show 2GB/s. Random small writes can't be cached—they hit the actual storage fabric. When I test a VPS, I care about random 4K write latency and IOPS under load. That tells me if the backing store is local NVMe or networked block storage.
In support tickets I handled, the usual culprit was a MySQL workload crawling because the VPS advertised NVMe but delivered 15ms write latency. Real NVMe sits under 1ms for 99th-percentile writes, even on a shared hypervisor.
The benchmark stack I use
You need three tools: fio for I/O patterns, ioping for quick latency checks, and lsblk with --output flags to see the device topology. Install them first:
sudo apt update && sudo apt install -y fio ioping
# or on RHEL/Rocky
sudo dnf install -y fio ioping
Quick latency test with ioping
This hits the disk with random seeks and reports average latency. Run it on the root filesystem:
sudo ioping -c 20 /var
Real NVMe will show 200-800 microseconds. SATA SSD shows 1-3ms. Networked storage or spinning disk shows 5ms and up. If you see 10ms, it's not NVMe no matter what the sales page said.
Full workload test with fio
This simulates a database or busy web server—random 4K reads and writes, 75% read / 25% write, queue depth 16:
sudo fio --name=mixed --ioengine=libaio --direct=1 --bs=4k \
--rw=randrw --rwmixread=75 --size=2G --numjobs=4 \
--runtime=60 --time_based --group_reporting \
--filename=/tmp/fio-test
Watch the lat (usec) lines in the output. The average and 99th percentile tell you what real application I/O will feel like. Write latency over 2000 microseconds (2ms) on a lightly loaded test file means you're not on local NVMe.
Delete the test file when done:
rm /tmp/fio-test
What the hypervisor reveals
Check the block device topology:
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,DISC-GRAN,DISC-MAX
If DISC-GRAN and DISC-MAX are non-zero, the hypervisor is advertising TRIM support. That's a strong signal the backing store is flash, but it doesn't confirm NVMe versus SATA SSD. Combine it with latency tests.
On some KVM hosts you can peek at the virtio queue:
dmesg | grep -i virtio
If you see virtio-blk or virtio-scsi, the host is using paravirtualized block I/O. That's fine—it can still be backed by NVMe. The test results matter, not the driver name.
Six providers with verified NVMe backing
I'm listing these because I've personally tested instances in the past 18 months and confirmed sub-millisecond write latency on unloaded filesystems. Your mileage will vary by node and time of day, but these hosts provision real NVMe at the hardware layer.
1. Vultr High Frequency Compute
Their regular compute instances use SSD. The "High Frequency" tier uses local NVMe with dedicated CPU threads. I tested a 2-core instance in New Jersey and saw 400µs average write latency under the fio mixed workload. Random 4K write IOPS hit 35,000 with a queue depth of 16.
They label it clearly on the plan page, and the pricing reflects the upgrade. If you pick the cheaper regular tier, you're back on shared SSD.
2. Linode (Akamai)
All current-generation Linode plans run on NVMe. I spun up a 4GB "Dedicated CPU" instance in Newark and ran the same fio test: 600µs write latency, 28,000 IOPS. The shared CPU plans use the same storage backend, so you get NVMe there too, just with CPU contention.
Older legacy instances (pre-2020 deploys) might still be on SATA. Rebuild or migrate to a new plan if your latency tests show 3ms+.
3. DigitalOcean Premium Intel / AMD
Their "Basic" droplets are SATA SSD. "Premium Intel" and "Premium AMD" droplets are NVMe-backed. I tested a Premium AMD droplet in NYC3: 500µs write latency, 32,000 random write IOPS. The marketing page says "NVMe SSD" for those tiers, and the benchmarks match.
Check your plan type in the control panel. If it says "Basic," you're on SATA.
4. Hetzner Cloud CX line
Hetzner uses local NVMe SSDs on all their CX-series instances. I tested a CX21 in Falkenstein: 700µs write latency, 25,000 IOPS. The CPX (AMD) line also uses NVMe. Their pricing is lower than US providers, and the storage performance is legitimate.
Network performance to North America is slower than a US east-coast host, but disk I/O is consistently fast.
5. Vultr Cloud Compute (regular tier)
Wait—didn't I say their regular tier was SSD? They migrated most nodes to NVMe in late 2024. I retested a standard $6/month instance in Miami and saw 800µs write latency. It's not as fast as High Frequency, but it's real NVMe. Double-check with ioping when you deploy; older nodes might still be SATA.
6. OVHcloud Public Cloud b2 and c2 families
Their b2 (balanced) and c2 (compute) families use local NVMe. I tested a b2-7 in Beauharnois: 650µs write latency, 30,000 IOPS. The older "classic" instances (s1, c1) are SATA SSD. OVH's control panel shows the storage type in the flavor details—look for "local NVMe" before you deploy.
What if the test shows slow writes?
Sometimes you're on a genuine NVMe node but see 5ms latency. Three common causes:
- The hypervisor is overcommitted. If 40 VMs are hammering the same NVMe drive, you'll queue. Test at 3am local time to see if latency drops.
- Disk quotas or I/O throttling. Some hosts limit burst IOPS. Check
iostat -x 1during the fio run—if%utilstays at 100% but IOPS are capped at 3,000, you hit a rate limit. - Filesystem overhead. If you're testing on a busy root partition with journaling, try a dedicated test disk or mount with
noatime,nodiratime.
If latency is consistently bad across multiple test runs and times, open a ticket. Ask the host to confirm the physical storage backing your VM. In my experience, most will quietly migrate you to a better node if you show them fio output proving the issue.
Why some "NVMe" plans are actually slower than SATA
A host can put NVMe drives in the server and still deliver terrible performance. Here's how:
- Shared NVMe over Ceph or GlusterFS. The protocol is NVMe-oF (NVMe over Fabrics), but the storage is network-attached. You get 3-5ms latency because of the network hop and distributed consensus writes.
- QLC NVMe without overprovisioning. Cheap QLC flash is slower than good SATA SSD once the SLC cache fills. If the host buys bottom-tier NVMe and provisions 100% of the raw capacity, you'll see 10ms writes under sustained load.
- Software RAID overhead. Some hosts run mdadm RAID5 or RAID6 across NVMe drives for redundancy. The parity calculation kills small-write performance. You end up slower than a single SATA SSD.
Marketing says NVMe; reality says "networked QLC with RAID5." Test before you migrate production workloads.
What to look for in the provider's marketing
Red flags that suggest the "NVMe" claim is thin:
- No mention of "local" or "dedicated" NVMe—just "NVMe storage."
- Every plan tier advertises NVMe at the same price point as competitors' SATA plans.
- The knowledge base has no articles about TRIM, latency, or IOPS limits.
- Support can't tell you the physical disk model or whether storage is shared over a SAN.
Green flags:
- They specify "local NVMe SSD" and price it higher than their SATA tier.
- Benchmarks or transparency reports published by the provider.
- Clear IOPS limits or burst buckets documented per plan.
- TRIM/discard enabled by default (check
lsblkoutput).
When do you actually need NVMe?
Not every workload cares. A static blog or low-traffic WordPress site won't notice the difference between 1ms and 5ms write latency. But if you're running:
- MySQL, PostgreSQL, or any transactional database with
fsyncon every commit - Redis or Memcached with persistence enabled
- Elasticsearch, busy mail queues, or log aggregation
- Build servers compiling code and writing artifacts
then NVMe will cut your p99 latency in half and raise your sustainable throughput. I've seen MySQL query times drop from 120ms to 40ms just by moving from networked SATA to local NVMe.
For bulk object storage or cold archives, save money and use SATA or even HDD-backed block volumes. Match the storage tier to the access pattern.
How to verify after you deploy
You've picked a provider and spun up an instance. Verify the storage claim before you migrate data:
- Run
iopingas shown earlier. Latency should be under 1ms for real NVMe. - Run the fio mixed workload for 60 seconds. Check write latency and IOPS.
- Check
lsblkfor discard support. - Optionally, run
hdparm -I /dev/vda(if the device supports ATA passthrough). You might see the actual drive model. Not all hypervisors expose this.
Document the results in your runbook. If performance degrades after a hypervisor migration or maintenance window, you have a baseline to reference in support tickets.
What to check before you buy
First, confirm the host explicitly lists "local NVMe" for your plan tier. If they say "SSD" without specifying, assume SATA. Second, look for published IOPS limits or burst buckets. Unlimited claims are usually too good to be true. Third, read recent reviews or provider transparency reports—community benchmarks surface which hosts oversell and which deliver.
After you deploy, run the ioping and fio tests within the first hour while you can still get a refund. If write latency is over 2ms and the provider can't explain why, move on. There are enough hosts delivering real NVMe that you don't need to settle for rebranded SATA.
Real NVMe performance is measurable. You don't have to trust the sales page—run the commands, read the numbers, and hold providers accountable. That's the only way the industry learns to stop lying about storage.