When you provision a VPS, the hosting panel shows "NVMe storage" in bold. Marketing pages promise blazing speed. But actual disk latency—the time your application waits for each read or write—can vary wildly between providers using the same underlying NVMe hardware.
I've tested dozens of VPS instances over the past two years, focusing on one metric: round-trip latency for small block I/O operations. Seven providers consistently delivered sub-0.1ms (100 microseconds) latency under typical workloads. This matters for database-heavy applications, real-time processing, and any workload where storage wait time compounds into user-facing slowness.
Why disk latency matters more than IOPS
IOPS (input/output operations per second) gets the spotlight in most hosting specs. A provider advertises 100,000 IOPS and you assume the disk is fast.
But IOPS measures throughput, not responsiveness. High IOPS can coexist with terrible latency if the queue depth is large or if the hypervisor batches I/O. Your web application making hundreds of small database queries cares far more about latency than raw throughput.
A disk with 50,000 IOPS and 0.08ms latency will feel faster than one with 150,000 IOPS and 0.5ms latency for typical web workloads. Each query completes sooner.
What creates latency in virtualized NVMe
NVMe SSDs on bare metal can hit 10-20 microseconds for a single read. Why do VPS instances rarely see that?
The hypervisor introduces overhead. KVM, Xen, and VMware all add paravirtualized storage drivers or virtio layers. Then there's the storage backend: some providers use Ceph or distributed storage with network hops. Others use local NVMe with thin provisioning that occasionally stalls when the hypervisor reclaims blocks.
Oversubscription matters too. If the host node runs 40 VMs sharing four NVMe drives, your latency depends on what your neighbors are doing. During a neighbor's backup or database rebuild, your 0.08ms can spike to 2ms.
The seven providers below either use local NVMe with light oversubscription or have tuned their storage stack to minimize virtualization overhead.
How to measure latency on your VPS
Before trusting any provider's claims, test your own instance. Install fio, the flexible I/O tester:
sudo apt update && sudo apt install -y fio
Run a simple random read latency test:
fio --name=randread --ioengine=libaio --iodepth=1 --rw=randread \
--bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 \
--time_based --group_reporting
Look for the clat (completion latency) percentiles in the output. The 50th percentile (median) should be under 100 microseconds (0.1ms) for a quality NVMe VPS. The 99th percentile tells you about tail latency—occasional slow I/O that can stall your application.
A second test for write latency:
fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite \
--bs=4k --direct=1 --size=512M --numjobs=1 --runtime=60 \
--time_based --group_reporting --fsync=1
The fsync=1 flag forces data to disk after each write, simulating database commit behavior. You'll see higher latency here—anything under 0.15ms is excellent.
Seven providers with consistent sub-0.1ms latency
These providers showed median read latencies below 100 microseconds across multiple test runs on their standard VPS plans. I tested from different regions and times of day to account for load variation.
Vultr High Frequency
Their high-frequency instances use NVMe with dedicated CPU cores. Median read latency consistently hit 0.06-0.08ms across US and European locations. Write latency with fsync averaged 0.12ms.
The regular Vultr instances (not high-frequency) showed more variation—0.15-0.3ms—so pay attention to which tier you're provisioning.
Linode (Akamai)
After the Akamai acquisition, Linode's infrastructure remained strong. Their shared instances delivered 0.07-0.09ms read latency. The dedicated CPU plans were slightly faster but the difference was marginal.
One quirk: during the first hour after provisioning, latency was higher (0.2-0.3ms) as the hypervisor pre-allocated blocks. After that, performance stabilized.
DigitalOcean Premium NVMe
Their premium droplets (distinct from the basic tier) showed 0.08-0.10ms median latency. Write latency was slightly higher at 0.14ms but still competitive.
Basic droplets varied more—sometimes 0.15ms, sometimes 0.4ms—likely due to heavier oversubscription.
Hetzner Cloud
Hetzner's CPX line (shared vCPU with NVMe) consistently delivered 0.07-0.09ms read latency. For the price, the performance is exceptional. European locations (Falkenstein, Nuremberg) were slightly faster than US-based instances, probably because those data centers are newer.
Write latency averaged 0.13ms with fsync.
OVHcloud
OVH's B2 and D2 instances (the ones explicitly labeled NVMe) showed 0.08-0.11ms latency. Older instance types still on SATA are slower—triple-check the storage type when ordering.
I saw more variation in 99th percentile latency here, occasionally spiking to 1.5ms, but the median remained solid.
UpCloud MaxIOPS
Their MaxIOPS storage tier is specifically tuned for latency. Median read latency was 0.06-0.08ms, matching Vultr's performance. Write latency with fsync was 0.11ms, the fastest I measured.
The standard tier (not MaxIOPS) was noticeably slower at 0.2-0.3ms, so the upgrade matters.
Kamatera
Less well-known in the developer community, but their NVMe instances delivered 0.08-0.10ms consistently. They offer hourly billing without monthly commitments, which made testing easier.
One downside: provisioning sometimes took 10-15 minutes compared to the near-instant spin-up on Vultr or DigitalOcean.
What about AWS, Azure, and GCP?
The big three cloud providers offer NVMe-backed instances, but with different performance profiles. AWS i3/i4i instances and Azure Lsv2/Lsv3 use local NVMe and can hit sub-0.1ms latency—but you're paying significantly more than the providers above.
Their general-purpose instances (AWS gp3 EBS, Azure Premium SSD, GCP persistent disk) sit behind network-attached storage and typically show 0.3-1ms latency. Fine for many workloads, but not in the same category as local NVMe.
If your application is already in AWS and needs low latency, use i-series instances with instance store volumes. Otherwise, the VPS providers above offer better price-to-performance for disk-latent workloads.
When sub-0.1ms latency actually matters
Not every application benefits from ultra-low storage latency. Static sites served from RAM, API gateways proxying requests elsewhere, or batch processing jobs are bottlenecked elsewhere.
You'll notice the difference with:
- High-transaction databases: MySQL, PostgreSQL, or MongoDB with many small writes. Each transaction waits for disk commits.
- Real-time analytics: Time-series databases like InfluxDB or TimescaleDB that ingest thousands of writes per second.
- Session stores: Redis or Memcached with persistence enabled, where checkpoint writes can cause latency spikes.
- Log aggregation: Tools like Elasticsearch or Loki writing and indexing log streams continuously.
- Application servers under load: PHP-FPM, Node.js, or Python apps making frequent file reads for templates, config, or cache.
If your monitoring shows disk wait time consuming a noticeable percentage of request duration, storage latency is your bottleneck.
Testing under load
The single-job fio tests above measure best-case latency. Real applications issue concurrent I/O. Test with higher queue depth to simulate load:
fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread \
--bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60 \
--time_based --group_reporting
This runs four jobs, each with 16 outstanding I/O operations. If median latency stays under 0.5ms and 99th percentile under 2ms, the provider handles concurrency well. If latency jumps to 5-10ms, the storage backend is saturated or the hypervisor is throttling.
Compare the results against your baseline single-job test. A small increase (2-3x) is normal; a large spike suggests oversubscription or poor QoS.
Beyond latency: IOPS limits and burst credits
Some providers cap IOPS even on NVMe. Check the fine print. A VPS might deliver 0.08ms latency but throttle you to 10,000 IOPS, which limits throughput for larger operations.
Others use burst credits (like AWS gp3). You get full performance for a few minutes, then drop to a baseline. For sustained workloads, baseline IOPS matter more than burst.
Run your fio tests for at least 60 seconds to see if performance degrades. If latency is stable for the first 30 seconds then doubles, you're hitting a rate limit.
Questions about NVMe VPS performance
Can SATA SSD match NVMe latency?
No. SATA SSDs typically deliver 0.5-1ms latency due to protocol overhead. Even a fast SATA drive can't break 0.3ms. NVMe's direct PCIe connection is fundamentally faster.
Does instance size affect latency?
Sometimes. Larger instances may get dedicated CPU cores or less-oversubscribed storage pools. I saw identical latency across 2GB and 8GB instances on most providers, but Vultr's smallest high-frequency instance was slightly slower (0.10ms vs 0.06ms on larger sizes).
What causes latency spikes in production?
Neighbor activity (noisy neighbor problem), hypervisor maintenance tasks, thin-provisioning block allocation, or snapshot operations. Check your provider's status page and correlate spikes with maintenance windows.
Is 0.1ms latency noticeable to end users?
Not directly. But 0.1ms per query times 50 database queries per request equals 5ms of disk wait. That compounds. Drop it to 0.05ms and you save 2.5ms per request—enough to affect page load time.
What to check before choosing a provider
Start with the actual storage type. "SSD" is vague; confirm it's NVMe, not SATA. Check if it's local NVMe or network-attached (SAN).
Ask about oversubscription ratios. Providers won't always share this, but support can hint at whether storage is shared across 10 VMs or 50.
Test before you commit. Most providers offer hourly billing. Spin up an instance, run the fio tests above, and check the numbers. Destroy the instance if performance doesn't match your needs.
Monitor latency in production. Install iostat and watch the await column, or use application-level metrics (database query time, cache hit latency). What you measure in fio should match what your application sees under load.
Finally, verify your application is actually bottlenecked by disk. Profile first. If CPU or network is the constraint, faster storage won't help.