![NVMe VPS Hosting: 7 Providers Benchmarked [2026]](/images/blog/nvme-vps-hosting-7-providers-benchmarked-2026-2.jpg)
Most VPS providers slap "NVMe" on their sales page and call it a day. The storage might be NVMe, but if it sits behind network bottlenecks, shared controllers, or thin-provisioned pools with fifty neighbors hammering the same drive, you won't see NVMe speeds. I ran identical benchmark workloads across seven hosts to separate real performance from marketing.
The test methodology
Every provider got the same treatment: a four-vCPU VPS with 8 GB RAM and 80 GB NVMe storage, deployed in their US East region where available. I installed Debian 12 minimal, updated the kernel, then ran three workloads within four hours of provisioning to avoid noisy-neighbor variance creeping in over days.
First: fio with random 4K reads and writes at queue depth 32, the pattern that separates real NVMe (hundreds of thousands of IOPS) from SATA SSDs pretending to be fast (maybe 10K IOPS on a good day). Second: a MySQL 8.0 benchmark with sysbench, running 10 million row inserts and then point-select queries to measure transactional storage performance under database load. Third: a file-tree compile test cloning a mid-sized Rust project and building it, which stresses both sequential and random I/O with tons of small file operations.
I repeated each test three times and took the median. These aren't multi-day burns to catch every edge case, but they expose the basics fast.
Provider one: DigitalOcean Droplets
DigitalOcean moved all Droplets to NVMe in 2020 and their performance has stayed consistent. Random 4K read IOPS landed in the mid-to-high five figures, write IOPS slightly lower but still well above SATA ceilings. The MySQL point-select benchmark completed with query latency averaging under two milliseconds, which is tight enough for most transactional apps.
Compile times on the Rust project hovered around what you'd expect from decent NVMe without thermal throttling. No obvious weak link. Their block storage volumes also use NVMe now, so attaching extra disks doesn't drag you back to SATA speeds.
The main knock: cost per IOPS isn't the cheapest on this list if you need tons of storage. But the performance floor is high and predictable.
Provider two: Vultr High Frequency
Vultr's High Frequency instances advertise NVMe and higher CPU clock speeds. Random read IOPS topped out in the same neighborhood as DigitalOcean, sometimes a hair higher. Random writes occasionally spiked lower during the second or third run, hinting at write-cache exhaustion or a neighbor waking up, but not consistently enough to disqualify them.
Database insert throughput was fast. Point selects came back with sub-two-millisecond latency most of the time. The file compile test finished slightly faster than DigitalOcean's median, likely thanks to those higher base clocks on the CPU side rather than storage alone.
Vultr's regular "Cloud Compute" tier also uses NVMe now, but High Frequency reserves dedicated CPU threads and seems to deliver tighter performance variance. If you're running a database or Redis instance that hammers storage constantly, the consistency matters more than peak numbers.
Provider three: Linode (Akamai)
Linode rebranded under Akamai but their VPS lineup still runs NVMe across the board. Random read IOPS came in strong, often matching or edging past Vultr. Write IOPS stayed stable across all three runs with no weird dips.
MySQL benchmarks showed slightly higher query latency than the first two (still under three milliseconds average), which isn't a disaster but suggests either a bit more I/O scheduler contention or tuning that favors throughput over latency. The Rust compile test landed in the middle of the pack—not the fastest, not slow.
Linode's big advantage is straightforward pricing with no surprise "High Frequency" upsell tiers. You get NVMe and a known-good network without decoding a matrix of instance families. For hosting a Rails app or a Postgres replica that needs reliable random I/O, they're solid.
Provider four: Hetzner Cloud
Hetzner's pricing is famously aggressive, especially for European customers, and their US presence has grown. All their Cloud instances use NVMe. Random read IOPS clocked in well above SATA but not quite as high as the top three, landing closer to the mid-five-figure range. Write IOPS were similar—plenty fast, but not record-breaking.
Database insert performance was good. Point-select latency averaged around three to four milliseconds, which is higher than DigitalOcean or Vultr but still acceptable for most web apps. The compile benchmark took a few seconds longer than the leaders, likely a mix of slightly lower IOPS and their CPU models running at lower base clocks.
The value proposition is hard to ignore. If you're spinning up dev environments, CI runners, or staging boxes where cost per instance matters more than squeezing every last IOPS, Hetzner delivers real NVMe performance at a fraction of the usual price. Production databases that live under constant heavy random I/O might prefer the tighter latency of the pricier hosts, but for most workloads the difference won't surface.
Provider five: Contabo VPS
Contabo advertises NVMe storage and their prices look too good to be true, which made me curious. Random read IOPS came back lower than every other provider on this list, sitting in the low-to-mid five figures. Random write IOPS were even softer, sometimes dipping into the high four figures during the third test run.
MySQL point-select latency spiked into the six-to-eight millisecond range during peak query load. That's not catastrophic, but it's noticeably slower than the others. The file compile test dragged on, taking nearly twice as long as the fastest host.
So what's happening? Contabo likely overcommits storage more aggressively or uses older NVMe controllers with higher queue contention. The drives might technically be NVMe, but the performance profile screams oversubscription. If you're hosting static sites, backups, or low-traffic WordPress installs that rarely touch the disk, you'll probably never notice. High-transaction databases or I/O-heavy build pipelines will struggle.
Provider six: OVHcloud Public Cloud
OVHcloud's Public Cloud instances offer NVMe across their ranges. Random read IOPS landed in the upper-mid five figures, a step below the top performers but well ahead of Contabo. Write IOPS tracked similarly—solid, not spectacular.
Database benchmarks showed query latency in the three-to-four millisecond range under load, similar to Hetzner. The Rust compile test finished in respectable time, not the fastest but not lagging behind badly either.
OVH's infrastructure is massive and their network backbone is fast, which helps when your VPS needs to push data out alongside serving local I/O. Pricing sits in the middle: not as cheap as Hetzner, not as expensive as DigitalOcean. They're a reasonable pick if you need NVMe performance combined with OVH's global footprint and DDoS mitigation.
Provider seven: AWS Lightsail
AWS Lightsail instances don't advertise NVMe explicitly, and after testing it's clear why. Random 4K read IOPS hovered in the low five figures, barely better than a fast SATA SSD. Write IOPS were similar. These aren't NVMe numbers.
MySQL query latency climbed into the eight-to-twelve millisecond range during heavy load, which would bottleneck any transaction-heavy app. The compile benchmark took longer than every other host except Contabo.
Lightsail's appeal is the predictable monthly price and tight integration with the rest of AWS if you're already running EC2, RDS, or S3 in the same account. But if raw storage performance is your priority, Lightsail won't compete with true NVMe providers. For hosting a low-traffic WordPress site or a cron-job server, it's fine. For anything that hammers the disk, look elsewhere.
NVMe vs SATA SSD: what the numbers mean
A SATA SSD tops out around 500-550 MB/s sequential throughput and maybe 10K-20K random IOPS if you're lucky. NVMe on PCIe 3.0 delivers 3-3.5 GB/s sequential and hundreds of thousands of random IOPS with sub-millisecond latency. That gap matters when your app does frequent small reads and writes—database queries, Redis operations, log writes, file uploads hitting temp storage.
If your workload is mostly sequential (video encoding, log shipping, backups), SATA SSD is often good enough and you'll never notice the difference. But transactional databases, key-value stores, and high-concurrency web apps that serve dynamic content see immediate gains from real NVMe.
The catch is marketing teams labeling anything remotely fast as "SSD" or "NVMe" without clarifying if the storage backend is actually NVMe or if it's networked block storage over iSCSI that adds 200+ microseconds of latency per I/O. Benchmarks cut through the noise.
What actually slows down "NVMe" hosts
Even with real NVMe drives, several factors kill performance. Oversubscription is the biggest one: the hypervisor lets 20 VMs share one physical NVMe drive, and when half of them wake up at once your IOPS crater. Thin provisioning can do the same thing—if the pool runs low on free space, writes slow to a crawl as the storage layer juggles block allocation.
Network-attached NVMe adds latency. Some providers use NVMe drives in a SAN and serve them to compute nodes over 25G or 100G links, which is fast but not as fast as local NVMe on the same PCIe bus. You'll see this in cloud environments where storage and compute are separate layers for flexibility, and the I/O latency creeps up to a few hundred microseconds instead of tens.
Old or budget NVMe controllers sometimes bottleneck at lower queue depths. Consumer-grade NVMe drives hit great sequential speeds but struggle with sustained random writes. Enterprise drives handle mixed workloads better, and hyperscale providers usually use data-center-grade Samsung, Intel, or Kioxia drives. Smaller hosts might cut costs with cheaper consumer NVMe, which shows up in benchmarks under load.
When SSD is enough and when you need NVMe
Static sites, file storage, CDN origin servers, and backup targets rarely stress random IOPS. Sequential throughput matters more, and a SATA SSD handles that fine. You'll save money going with a cheaper tier.
Databases (MySQL, Postgres, MongoDB), key-value stores (Redis, Memcached with persistence), search indexes (Elasticsearch), and anything doing transactional writes benefit immediately from NVMe. Lower latency translates to more queries per second and tighter response times under concurrent load.
Build servers and CI runners doing lots of small file operations (cloning repos, compiling, linking, running tests) also see big wins. A 30-second build on SATA might drop to 15 seconds on real NVMe, which compounds when you run dozens of builds daily.
Checking your actual disk performance
Install fio and run a quick random I/O test to see what you really get:
sudo apt update && sudo apt install -y fio
fio --name=randread --ioengine=libaio --rw=randread --bs=4k --size=1G --numjobs=4 --runtime=60 --time_based --group_reporting --iodepth=32
Random read IOPS above 50K with NVMe is baseline. Below 20K suggests SATA or heavy oversubscription. Run the same test with --rw=randwrite and check write IOPS too—some hosts tune for reads and sacrifice write performance.
For database workloads, install sysbench and run the oltp_read_write benchmark against a local MySQL or Postgres instance. Query latency under load tells you more than raw IOPS in isolation.
sudo apt install -y sysbench mysql-server
sysbench oltp_read_write --mysql-user=root --mysql-db=test --tables=10 --table-size=100000 prepare
sysbench oltp_read_write --mysql-user=root --mysql-db=test --tables=10 --table-size=100000 --threads=8 --time=60 run
Average query latency below 5ms under multi-threaded load is solid. Above 10ms means the storage can't keep up.
What the benchmarks actually tell you
Raw IOPS numbers give you a performance ceiling, but real-world latency under mixed load matters more. A host delivering 80K random read IOPS with consistent 1ms latency beats one spiking to 120K IOPS but with 10ms latency variance when neighbors get noisy.
DigitalOcean, Vultr, and Linode showed the tightest performance and the most predictable latency across repeated tests. Hetzner and OVHcloud traded a bit of peak speed for better pricing, still landing well above SATA territory. Contabo and AWS Lightsail both underdelivered on NVMe performance, with Contabo likely oversubscribing and Lightsail not using NVMe at all.
Pick your host based on the workload. Databases and key-value stores need low latency and high random IOPS, so go with the top tier. Static sites and file servers can save money on the mid-tier hosts without sacrificing much. And if a deal looks too cheap, benchmark it yourself before migrating production traffic.