Picking a VPS provider used to mean reading marketing copy about "blazing fast NVMe" and "enterprise-grade networks." Now you can cut through that by running the same benchmarks I use in support work—boot time, network latency to major regions, and disk I/O under load. I tested nine providers in early 2026 using their entry-level and mid-tier plans.
Each host got a fresh Ubuntu 24.04 LTS instance. Same kernel, same tools, same test scripts. This isn't about finding the absolute fastest hardware—these are shared VPS nodes, after all—but about spotting patterns: which providers over-provision, which throttle disk writes after the first gigabyte, and which have routing problems to Asia or Europe.
Why these three metrics matter
Boot time tells you if the hypervisor is overloaded. A two-second boot means the host isn't starved for CPU scheduling. Twelve seconds suggests noisy neighbors or an oversubscribed node.
Network latency between your VPS and your users affects every HTTP request, database query, and API call. If you serve customers in Singapore and your VPS routes through Frankfurt first, that's 180 ms you can't get back with caching.
Disk I/O separates real NVMe from SATA SSDs behind a caching layer. It also exposes I/O throttling policies—some providers give you full speed for the first few minutes, then cut throughput by half. That hurts during backups, log rotation, and apt upgrades.
Testing methodology
I deployed one instance per provider, waited 24 hours for any provisioning burst credits to normalize, then ran three test passes over 48 hours. All tests ran during business hours UTC to catch realistic load.
Boot time test
Used systemd-analyze after a clean reboot. Measured kernel boot plus userspace init, not BIOS/UEFI handoff since that's hypervisor overhead. Took five samples per host and averaged the middle three.
systemd-analyze time
Network latency test
Measured round-trip time to eight public mirrors: four in North America, two in Europe, one in Singapore, one in Sydney. Used mtr with 100 packets to catch jitter, not just ping averages. Routed through the VPS default gateway—no tunnels or CDN in front.
mtr -c 100 -r mirror.example.com
Disk I/O test
Ran fio with three workloads: sequential writes (simulates backups), random reads (simulates database access), and mixed 70/30 read-write (simulates typical app load). Each test wrote 4 GB to avoid fitting in RAM cache. Used direct I/O to bypass the kernel page cache.
fio --name=seqwrite --rw=write --bs=1M --size=4G --direct=1
fio --name=randread --rw=randread --bs=4k --size=4G --direct=1 --numjobs=4
fio --name=mixed --rw=randrw --rwmixread=70 --bs=4k --size=4G --direct=1
All tests logged results to JSON so I could compare apples to apples.
The nine providers
I tested DigitalOcean, Linode (now Akamai), Vultr, Hetzner, OVHcloud, UpCloud, Contabo, IONOS, and Kamatera. Plans ranged from $5 to $12 per month for 2 vCPU and 2-4 GB RAM. Picked the nearest datacenter to London for European tests and New York for US tests.
Each provider markets something different—DigitalOcean talks about developer experience, Hetzner advertises price, UpCloud focuses on MaxIOPS storage. The question is whether those claims hold up under measurement.
Boot time results
Fastest boots came from Vultr and UpCloud: 1.8 to 2.3 seconds consistently. That suggests low hypervisor contention and fast storage backing the root filesystem.
Linode and DigitalOcean landed in the middle at 3 to 4 seconds. Still fast, but you notice the difference when scripting mass deployments or testing infrastructure-as-code that provisions and destroys instances.
Hetzner surprised me with 5-second boots despite their low prices. The variability was tight, though—five samples all within 200 ms of each other.
Contabo and IONOS hit 8 to 11 seconds. That's a red flag for oversubscription. In support tickets I handled, slow boots usually meant the host was paging to disk under memory pressure or the IOPS quota was already exhausted by other tenants.
Kamatera and OVHcloud sat in between at 5 to 7 seconds. Acceptable but not impressive.
Network latency patterns
From London to other European cities, Hetzner and OVHcloud had the cleanest routes: 8-15 ms to Frankfurt, Paris, Amsterdam. Their backbone peering is solid. Vultr and UpCloud were close behind at 12-18 ms.
DigitalOcean and Linode added an extra hop through their internal network fabric, pushing latency to 18-25 ms within Europe. Not a dealbreaker, but visible in traceroutes.
Transatlantic latency (London to New York) was tightest on DigitalOcean and Linode at 72-78 ms. Hetzner came in at 80-85 ms. Contabo hit 95-105 ms with noticeable jitter—mtr showed packet loss on one of their transit links.
Asia-Pacific latency mattered most for the Singapore and Sydney targets. UpCloud and Vultr kept RTT under 180 ms to Singapore from their EU nodes. Contabo and IONOS routed through two extra exchanges, adding 40-60 ms.
If your users are in Asia and you're hosting in Europe, that routing tax compounds. Every database query, every API call, every image fetch pays it.
Disk I/O breakdown
Sequential write speed separates NVMe from everything else. UpCloud hit 1100-1300 MB/s, Vultr reached 950-1100 MB/s, and Linode managed 850-950 MB/s. Those numbers mean backups and log shipping don't bottleneck on disk.
Hetzner delivered 700-800 MB/s—impressive given their pricing. DigitalOcean came in around 600 MB/s, which is fine for most web apps but might slow down large database restores.
Contabo and IONOS showed bimodal behavior: 900 MB/s for the first gigabyte, then dropped to 150-200 MB/s. That's a burst credit system kicking in. If you run monthly backups, you'll hit that throttle every time.
Random read IOPS matter for databases and any app with a working set larger than RAM. UpCloud led at 45k-50k IOPS, followed by Vultr at 38k-42k. Linode and DigitalOcean clustered around 25k-30k IOPS.
Hetzner again punched above its price point with 28k-32k IOPS. Contabo lagged at 8k-12k IOPS after the burst window closed—that's barely faster than a good SATA SSD.
Mixed 70/30 read-write workloads (which mirror real application patterns more closely) showed similar rankings. UpCloud stayed on top, Vultr and Linode traded second place depending on the run, and Contabo consistently placed last once throttling engaged.
What the results mean for your workload
If you're running a WordPress site with object caching and a CDN in front, disk I/O rarely matters—you're mostly CPU-bound during PHP-FPM spikes. Network latency to your CDN origin does matter, so pick a host with clean peering.
For a database-heavy app (Django + Postgres, Rails + MySQL), random read IOPS become critical once your working set exceeds RAM. Hosts like UpCloud and Vultr will keep queries under 10 ms. Hosts with 8k IOPS will queue reads and you'll see 50-100 ms query times during traffic spikes.
If you ship log files to S3 or run nightly backups, sequential write speed determines whether your backup window is 10 minutes or 90 minutes. Burst credits complicate this—Contabo looks fine in a 30-second test but terrible during a real 20 GB backup.
Boot time mostly matters during scaling events or incident recovery. If your deployment scripts create and destroy instances frequently, those extra eight seconds per boot add up. For a long-lived VPS you reboot quarterly, it's irrelevant.
Price-performance sweet spots
Hetzner offers the best raw value: decent I/O, low latency within Europe, and prices 40% below DigitalOcean. The tradeoff is fewer datacenter locations and less hand-holding in the control panel.
Vultr and UpCloud tie for performance, but UpCloud costs 50-70% more. That premium buys you MaxIOPS storage and tighter SLAs. Worth it if you're running production databases; overkill for staging environments.
DigitalOcean and Linode charge mid-range prices for mid-range performance. You're paying for mature APIs, good documentation, and a huge library of community tutorials. If you value developer experience and ecosystem, that's a fair trade.
Contabo tempts with ultra-low prices but penalizes you with throttling and routing inefficiencies. Fine for a personal project or a Discord bot. Not fine for anything user-facing.
Testing your own provider
Don't trust my benchmarks or anyone else's—providers change hardware, oversell nodes, and shift routing policies.
Spin up a test instance and run the same fio commands. Check if sequential writes stay consistent across a 10 GB test, or if they crater after two gigabytes. That reveals quota policies the sales page won't mention.
Use mtr to your actual users' locations, not generic public mirrors. If 80% of your traffic comes from Brazil, test latency to São Paulo.
Reboot the instance five times and check systemd-analyze. If boot time varies by more than two seconds between runs, the host is unstable or oversubscribed.
Run tests during peak hours (14:00-18:00 UTC for European hosts, 18:00-22:00 UTC for US East). Off-peak performance means nothing if your users hit the site during the dinner rush.
What to check before committing
Does the provider throttle after burst credits?
Run a 30-minute I/O test, not a 30-second one. Watch for the cliff where throughput drops by 70%. If you find it, decide whether your workload fits inside the burst window.
How does latency hold up under load?
Measure ping times while running a CPU stress test (stress-ng --cpu 2 --timeout 300s). Some hypervisors deprioritize network interrupts under CPU load. You'll see latency jump from 12 ms to 80 ms.
Can you reach your users efficiently?
Trace routes to your top three traffic sources. Count hops and look for > 10% packet loss on any single hop. One bad peering agreement ruins everything downstream.
What's the noisy neighbor situation?
Schedule tests at 02:00, 10:00, and 18:00 local time for the datacenter. If performance swings wildly by time of day, the host is overselling and your neighbors' batch jobs are stealing your I/O.
How fast is support?
Open a ticket asking a technical question (not sales). Time the first response. Check if they answer the actual question or paste a knowledge base link. You'll need them during an outage.
Which metrics matter most
Start with latency to your users. That's non-negotiable physics. A poorly routed VPS adds 50-100 ms you can't optimize away.
Next, match disk I/O to your workload. If you write more than you read (log aggregation, backup storage), sequential write speed and throttling policies matter most. If you read randomly (database, search index), IOPS matter most.
Boot time is a tiebreaker unless you auto-scale aggressively. Then it's the difference between handling a traffic spike and dropping requests while instances provision.
Price only matters after you've cleared the performance bar. Saving $3 per month doesn't help if your database queries time out during traffic spikes.