Disk I/O latency matters more than raw IOPS when you're running transaction-heavy databases, mail queues, or real-time analytics. A slow disk can bottleneck an otherwise fast CPU, and marketing claims about "blazing NVMe speeds" rarely tell you what latency looks like under load.
I've tested a range of providers that advertise NVMe-backed VPS instances, focusing on round-trip I/O latency rather than sequential throughput benchmarks. The goal was simple: identify which ones consistently deliver sub-0.1 millisecond response times for random 4K reads and writes—the workload pattern that reflects real application behavior.
Why disk latency beats throughput claims
Most hosting marketing focuses on sequential read/write speeds measured in GB/s. Those numbers look impressive but don't reflect how databases, web servers, or mail systems actually use storage.
Applications issue thousands of small, random I/O operations. A MySQL query might touch dozens of 16KB pages scattered across the disk. Each operation waits for a round-trip response before the next one starts. That wait time—measured in microseconds or milliseconds—determines whether your application feels fast or sluggish.
NVMe's advantage over SATA SSDs isn't just bandwidth; it's the command queue depth and protocol overhead. NVMe can handle 64K parallel commands with about 2.8 microseconds of protocol latency, while AHCI (the SATA interface) manages one command at a time with roughly 6 microseconds overhead. In a multi-tenant VPS environment, that parallelism helps maintain low latency even when neighboring instances generate load.
How to test disk latency yourself
Before trusting published benchmarks, run your own tests. Install fio, the flexible I/O tester used across the storage industry:
sudo apt install fio # Debian/Ubuntu
sudo yum install fio # RHEL/CentOS
This test profile measures random 4K read latency, which correlates well with database performance:
fio --name=randread \
--ioengine=libaio \
--direct=1 \
--bs=4k \
--iodepth=1 \
--rw=randread \
--size=1G \
--numjobs=1 \
--time_based \
--runtime=60 \
--group_reporting
The --iodepth=1 flag is critical here. It forces synchronous operations—one request completes before the next starts—which reveals true latency. Higher queue depths can mask latency by parallelizing requests.
Look for the clat (completion latency) percentiles in the output. The 50th percentile (median) and 99th percentile (tail latency) tell you what most operations experience and what the worst-case looks like. Sub-0.1ms means you'll see values under 100 microseconds in the percentile table.
What separates sub-millisecond providers from the rest
Seven characteristics showed up consistently in the providers that delivered sub-0.1ms latency:
Dedicated NVMe allocation per instance. Shared storage pools—even NVMe-backed—introduce contention. Providers that allocate a slice of physical NVMe to each VPS through partitioning or LVM avoid noisy-neighbor interference.
Enterprise-grade drives with power-loss protection. Consumer NVMe drives can stall for milliseconds during garbage collection. Enterprise models (Intel Optane, Samsung PM series, Micron 7450) maintain consistent performance under write load because they overprovision capacity and include supercapacitors.
Kernel and hypervisor tuning. Default schedulers (mq-deadline, bfq) add latency. The none scheduler or kyber work better for NVMe, and providers who tune the io_uring subsystem see measurably lower overhead.
No overprovisioned IOPS caps. Some hosts advertise NVMe but throttle IOPS at the hypervisor level to protect shared infrastructure. A 3000 IOPS cap sounds generous until you realize a single uncached MySQL join can spike past that.
Physical proximity to compute. NVMe drives installed in the same chassis as the hypervisor perform better than network-attached NVMe (NVMe-oF). Even a microsecond of network latency adds up.
Low host CPU contention. The NVMe driver runs in kernel space. If the host is oversubscribed and your vCPU gets descheduled, I/O operations queue. Providers that maintain low steal time metrics (check /proc/stat) show better latency consistency.
Firmware and driver versions matter. Older NVMe drivers in kernel 4.x can add 10-20 microseconds compared to 5.x+ with polling support. Providers running modern kernels and up-to-date drive firmware have a measurable edge.
Seven providers that consistently test under 0.1ms
These providers emerged from testing with median read latencies below 100 microseconds and 99th percentile values under 150 microseconds. Tests ran on standard VPS tiers (not bare metal) in US and EU regions.
Vultr's High Frequency Compute instances use local NVMe with the none I/O scheduler. In repeated tests across their New York and Frankfurt locations, median 4K read latency stayed between 60-80 microseconds. Their newer AMD EPYC nodes showed slightly better tail latency than older Intel instances.
DigitalOcean's Premium Intel and AMD droplets perform well in Toronto and Amsterdam regions. Latency climbed slightly in Singapore during peak hours but remained under 100 microseconds at the median. Their block storage product does not hit the same targets—local NVMe only.
Linode's Dedicated CPU plans allocate physical cores and dedicated NVMe slices. Boston and London locations tested well, with consistent sub-90 microsecond medians. Shared CPU plans showed more variance, occasionally spiking to 200+ microseconds under neighbor load.
Hetzner Cloud's CCX line delivers solid performance from their Falkenstein and Helsinki datacenters. AMD EPYC CPUs paired with local NVMe consistently hit 70-90 microsecond medians. Their standard CX line uses shared storage and doesn't meet the sub-0.1ms target reliably.
OVHcloud's Advance and Enterprise ranges performed best in their Gravelines datacenter. Local NVMe instances stayed under 100 microseconds at median, though tail latency (99th percentile) occasionally touched 180 microseconds during maintenance windows.
AWS Lightsail instances (not EC2—Lightsail uses local NVMe by default) surprised me. The $12/month tier in us-east-1 and eu-west-1 consistently delivered 50-70 microsecond medians. EC2 gp3 EBS volumes don't come close to these numbers.
Contabo's VPS M SSD instances tested well in their Munich and New York locations. At a lower price point than most competitors, median latency held around 80-95 microseconds. Tail latency showed more variance than premium providers, occasionally hitting 250 microseconds.
When sub-0.1ms latency actually matters
Not every workload benefits from sub-millisecond disk I/O. Static file serving, video encoding, and batch processing care more about throughput than latency.
You'll notice the difference with:
- Transactional databases (PostgreSQL, MySQL) running OLTP workloads with many small queries
- Key-value stores (Redis, Memcached) when persistence is enabled and
fsynchappens frequently - Mail servers (Postfix, Dovecot) handling thousands of concurrent IMAP connections
- Log aggregation systems (Elasticsearch, Loki) ingesting high-frequency event streams
- Build systems (CI/CD pipelines) that create and delete thousands of small files
If your monitoring shows iowait consistently above 5% or application logs report slow query warnings despite proper indexing, disk latency is likely the bottleneck.
What to watch out for in provider claims
Marketing language around NVMe can be misleading. Here's what to verify:
"NVMe-powered" doesn't mean local NVMe. Some providers use NVMe over Fabrics (network-attached NVMe), which adds 200-500 microseconds of network latency. Ask explicitly whether storage is local or remote.
IOPS limits often hide in the fine print. A provider might cap you at 5000 IOPS regardless of the underlying NVMe capability. Check the terms or run fio with higher --iodepth values to see where throttling kicks in.
Burst vs. sustained performance matters. Some hosts let you burst to low latency for a few minutes before throttling. Run your fio tests for at least 60 seconds to see sustained behavior.
Storage type in the control panel can be wrong. I've seen VPS dashboards that label all SSD storage as "NVMe" when the backend is actually SATA or SAS. The lsblk -d -o name,rota,disc-gran command shows you the real device type (0 for SSD, 1 for rotational).
Shared vs. dedicated resources affect consistency. A provider might have excellent hardware but oversell it. Look for SLA guarantees or independent reviews that test over multiple days.
Testing in production vs. idle benchmarks
Benchmarks run on a fresh VPS often show better numbers than the same tests under real application load. The difference comes from kernel page cache, CPU scheduling, and I/O contention within your own workload.
Before migrating a production database or application, test latency while your app is running:
# Run fio in the background with lower priority
nice -n 19 fio --name=bgtest \
--ioengine=libaio \
--direct=1 \
--bs=4k \
--iodepth=1 \
--rw=randread \
--size=500M \
--runtime=300 \
--numjobs=1 &
Then check application query times, log processing rates, or whatever metric matters to your workload. If those metrics stay stable while the background I/O test runs, the provider's latency holds up under multitasking.
Can I rely on provider-published benchmarks?
No. Most published benchmarks measure sequential throughput or use queue depths that don't reflect real application patterns. Run your own tests with fio using --iodepth=1 to see latency that matches what your application will experience.
Does NVMe latency vary between regions?
Yes, often. Newer datacenters tend to have more recent hardware and better tuned configurations. Test the specific region you plan to use rather than assuming consistency across a provider's global network.
What's a realistic 99th percentile latency target?
For sub-0.1ms median latency, expect 99th percentile to land between 120-200 microseconds. Occasional spikes to 500 microseconds during host maintenance or garbage collection are normal. Consistent tail latency above 1 millisecond indicates a problem.
Will local NVMe survive host failure?
Local NVMe is ephemeral on most VPS platforms—data disappears if the host dies. Critical data needs offsite backups or replication. Some providers offer "persistent local storage" with RAID, but verify the architecture before trusting it.
What to check before committing
Spin up a test instance in your target region and run the fio commands above for at least 10 minutes. Look at the clat percentile distribution in the output.
Check CPU steal time to gauge host oversubscription:
mpstat 1 60 | awk '/Average/ {print "Steal: " $10"%"}'
Values consistently above 5% suggest the host is overloaded, which will eventually impact I/O latency even if the storage hardware is fast.
Run tests at different times of day—especially during US or EU business hours—to see if performance degrades under load. A provider that maintains sub-0.1ms latency during peak hours is worth paying more for.