Choosing a VPS provider often comes down to who delivers the fastest disk, lowest network jitter, and quickest instance launches. Marketing pages promise "blazing speed" and "enterprise-grade performance," but without real tests you're flying blind.
I benchmarked nine popular VPS providers using the same test suite on their entry-level and mid-tier Linux instances. Boot time, network latency, and disk IO matter because they directly affect your app's responsiveness, deployment speed, and database performance. Here's what the tests revealed.
The testing methodology
Every provider got the same treatment. I spun up a fresh Ubuntu 22.04 instance (the most common choice) on each platform, waited five minutes for system initialization, then ran three tests:
- Boot time — measured from API call to SSH accessibility using a simple loop that attempts connection every second.
- Network latency — ran
mtrto eight geographically distributed targets (US East, US West, EU, Asia) for 100 pings each and recorded median latency. - Disk IO — used
fiowith a 4K random read/write workload for five minutes, logging IOPS and throughput.
All tests ran twice, once on the smallest plan (1-2 vCPU) and once on a mid-tier plan (4 vCPU). I picked the US East datacenter for every provider to keep networking apples-to-apples. No caching or tuning; just stock images.
Why these three metrics
Boot time tells you how fast your infrastructure responds when you scale horizontally or recover from failure. A provider that takes four minutes to boot is painful during traffic spikes.
Network latency shows routing efficiency. Low latency to your users matters more than raw bandwidth for most web apps — a 200ms ping adds 200ms to every uncached request.
Disk IO directly controls database query speed, log write throughput, and compile times. A slow disk chokes everything.
The providers tested
I focused on established names that support hourly billing and have multiple datacenter regions:
- DigitalOcean (Droplets)
- Linode (Akamai Cloud Compute)
- Vultr (Cloud Compute)
- Hetzner Cloud
- AWS Lightsail
- Google Cloud (E2 instances)
- Azure (B-series)
- OVHcloud (VPS)
- UpCloud
Most developers recognize these names. Each offers a Linux VPS with root access, block storage options, and API provisioning. Prices range from around four dollars to fifteen per month for the entry tier.
Boot time results
Boot time varied wildly. The fastest providers brought instances online in under thirty seconds from API call to SSH ready. The slowest took over three minutes.
DigitalOcean and UpCloud consistently booted in the twenty to thirty second range. Hetzner and Vultr hovered around forty-five seconds. Linode took about a minute. AWS Lightsail and Azure both exceeded two minutes on the entry tier, though Azure improved significantly on the larger instance size.
Google Cloud E2 instances took the longest — nearly three minutes on the small plan. OVHcloud sat in the middle at roughly ninety seconds.
Why does this matter? Autoscaling. If your app needs to respond to traffic spikes by launching new instances, a thirty-second boot gives you breathing room. A three-minute boot means users hit errors before your infrastructure catches up.
The surprising Azure variance
Azure B-series instances showed the widest spread. The first boot attempt took over four minutes; the second took just under two. This suggests cold-start penalty or backend resource contention. On the 4-vCPU tier the variance disappeared and boot time dropped to around seventy seconds consistently.
Network latency findings
Median ping times to US East Coast targets (where the VPS sat) ranged from 0.8ms to 3ms for all providers — no meaningful difference. The picture changed when testing cross-country and international routes.
Hetzner showed excellent routing to European targets, often beating US-based providers by twenty to thirty milliseconds. No surprise since their backbone is EU-centric. DigitalOcean and Vultr both delivered solid performance to US West Coast targets with median pings around 65-70ms.
AWS Lightsail and Google Cloud had slightly higher latency variance (jitter) than the others, likely because they share infrastructure with larger cloud platforms where traffic patterns are less predictable. Linode and UpCloud showed the most consistent routing with low jitter across all targets.
OVHcloud had higher latency to Asian targets compared to most competitors. Azure performed well globally but showed occasional spikes in the MTR results — brief moments where ping jumped to 150ms then returned to normal.
The routing question
So what causes good routing? Peering agreements, backbone quality, and traffic shaping. Smaller providers like Hetzner or UpCloud often buy premium transit and peer directly with major networks. Cloud giants like AWS rely on their own global backbone, which usually performs well but can introduce extra hops.
If your users are primarily in one region, pick a provider with a datacenter there and check their looking glass or MTR tools before committing.
Disk IO performance
This is where differences were stark. IOPS ranged from under 3,000 on the slowest to over 40,000 on the fastest.
UpCloud took the top spot with NVMe-backed storage delivering 40,000+ random read IOPS on even the small instance. DigitalOcean and Vultr both offered NVMe on their standard plans and hit 25,000-30,000 IOPS. Hetzner came in slightly lower at around 20,000 IOPS.
Linode's performance depended on the plan tier. The entry-level Nanode delivered roughly 8,000 IOPS; the 4-vCPU instance jumped to 18,000. AWS Lightsail and Google Cloud both capped out around 10,000 IOPS on entry tiers, improving to 15,000-18,000 on larger plans.
Azure B-series instances were the slowest, barely breaking 5,000 IOPS on the small plan. The 4-vCPU tier improved to about 12,000 but still lagged behind others. OVHcloud sat in the middle with 12,000-15,000 IOPS across both test sizes.
Why IOPS matter more than throughput
Most hosting workloads — databases, caching layers, web servers — do lots of small reads and writes. IOPS measure how many operations per second the disk can handle. High IOPS mean your MySQL queries return faster and your Redis cache doesn't bottleneck.
Sequential throughput (MB/s) matters for video processing or backups but not for typical web apps. A provider advertising "500 MB/s throughput" might still choke on random 4K operations.
Price-performance considerations
Fastest doesn't always mean best value. UpCloud delivered top-tier disk IO but costs more per month than DigitalOcean or Vultr. Hetzner offered excellent bang-for-buck with solid performance at lower prices than US providers.
AWS Lightsail and Azure are convenient if you're already invested in those ecosystems, but standalone VPS buyers get better raw performance elsewhere for the same money. Google Cloud E2 instances sit in a similar boat — fine if you need GCP integration, but not competitive on pure speed per dollar.
For budget-conscious projects that still need speed, Vultr and Hetzner hit the sweet spot. For mission-critical workloads where disk performance matters most, UpCloud or DigitalOcean justify the extra cost.
Real-world performance factors
Benchmarks don't tell the whole story. Network consistency matters as much as peak throughput. I've seen providers with great benchmark numbers suffer during evening peak hours when the hypervisor gets noisy neighbors.
Storage type makes a huge difference. NVMe beats SATA SSD by a mile. Some providers still offer older SSD or even spinning disks on legacy plans. Always check the spec sheet.
CPU allocation models vary too. Some providers guarantee dedicated cores; others use shared or burstable models where your vCPU only gets full power intermittently. This doesn't show up in a five-minute benchmark but kills performance under sustained load.
The noisy neighbor problem
Virtualized environments share physical hardware. If another VM on your host suddenly hammers the disk or network, your performance drops. Providers with good resource isolation (CPU pinning, IO throttling, separate storage networks) minimize this. Smaller providers often have better isolation because they're not cramming hundreds of VMs onto each host.
Anecdotally, DigitalOcean and Linode both use resource limits that prevent one customer from starving others. Azure and AWS sometimes show performance variation that suggests less strict isolation.
What to prioritize for your workload
Database-heavy apps need disk IOPS first. PostgreSQL and MySQL performance scales almost linearly with random read IOPS. If your app runs a lot of queries, pick UpCloud, DigitalOcean, or Vultr.
API servers and microservices care about network latency and boot time. Fast boot lets you scale quickly; low latency keeps response times tight. Linode, Vultr, and UpCloud all excel here.
Batch processing or CI/CD workloads want CPU and sequential disk throughput. Boot time matters less since jobs run for minutes or hours. Most providers handle this fine; focus on core count and memory instead.
For multi-region or global apps, check each provider's datacenter locations and routing quality from your target markets. Hetzner dominates Europe; DigitalOcean and Vultr have solid global presence; UpCloud offers excellent Nordic and US coverage.
Testing your own setup
Don't just trust benchmarks — test your actual workload. Spin up a trial instance, deploy your app, and measure what matters to you.
For disk IO, install fio and run a workload that matches your usage:
sudo apt-get install fio
fio --name=random-rw --ioengine=libaio --iodepth=32 --rw=randrw \
--bs=4k --direct=1 --size=1G --numjobs=4 --runtime=300 \
--group_reporting
For network, use mtr to your users' locations:
sudo apt-get install mtr
mtr -r -c 100 target-hostname.com
For boot time, record your deployment script runtime or measure SSH availability after instance creation.
Run tests during both off-peak and peak hours. Performance at 3 AM doesn't predict performance at 6 PM.
Which metrics should drive your decision
Pick based on your bottleneck. Database-bound apps need disk IOPS. User-facing APIs need low latency. Autoscaling setups need fast boot.
Benchmarks give you a starting point but your workload is unique. Testing on your target provider's platform for a few days reveals more than any chart. Most offer trials or hourly billing — use them. Boot a test instance, run your stack, measure what matters to your users, and make the call based on real data.