You want a VPS that boots fast, responds quickly, and handles disk writes without choking. Marketing pages promise blazing speed, but benchmarks tell the real story.
I tested nine popular VPS providers using the same standardized tests across identical instance sizes. Boot time, network latency from multiple locations, and disk I/O under load. The goal: find which providers deliver measurable performance, not just claims.
Why These Metrics Matter
Boot time matters when you're scaling horizontally or recovering from a failure. A provider that takes four minutes to spin up a new instance slows down autoscaling and incident response.
Network latency affects every HTTP request, database query, and API call your application makes. An extra 20ms on every round trip adds up fast. Disk I/O determines how quickly your application can read logs, write session data, and query a local database.
These three metrics form the foundation of VPS performance. CPU benchmarks fluctuate with noisy neighbors; these metrics reveal the infrastructure underneath.
Test Methodology
Each provider was tested on their entry-level VPS tier, typically 1-2 vCPU and 2GB RAM. I used fresh Ubuntu 22.04 LTS instances with no customization beyond SSH key setup.
Boot time: measured from API provision call to SSH availability using a scripted loop that attempted connection every second. Timed the full cold start, not a reboot of an existing instance.
Network latency: ran ping tests from five geographic locations (US East, US West, Europe, Asia, Australia) using distributed monitoring nodes. Measured average RTT over 100 ICMP packets per location. Also tested TCP handshake time to port 22.
Disk I/O: used fio with a mixed read/write workload simulating a database under moderate load. Random 4K operations with a 70/30 read/write split, direct I/O to bypass cache. Ran for 60 seconds after a 10-second warmup.
All tests ran during peak hours (US business day) to catch performance under real-world load, not 3 AM off-peak conditions.
The Nine Providers
I selected providers commonly recommended in hosting communities and support tickets. Mix of traditional hosts and cloud-focused platforms:
- DigitalOcean (Droplet, Regular Intel)
- Linode (now Akamai)
- Vultr (Regular Performance)
- Hetzner Cloud
- OVHcloud (VPS SSD)
- Contabo (VPS S SSD)
- AWS Lightsail
- Google Cloud (e2-micro equivalent tier)
- Azure (B1s)
The big three cloud providers were included because many developers start there, but their entry tiers aren't optimized for consistent performance.
Boot Time Results
DigitalOcean and Linode both provisioned in under 30 seconds consistently. SSH became available 15-20 seconds after the API returned a success status.
Vultr and Hetzner were similar, typically 25-35 seconds. Hetzner occasionally hit 45 seconds during EU peak hours but remained fast otherwise.
AWS Lightsail and OVHcloud took 60-90 seconds. Not terrible, but noticeable when you're waiting for a deployment to finish.
Contabo was the outlier at 2-4 minutes. Their provisioning system seems to queue requests, causing unpredictable delays.
Google Cloud and Azure's micro tiers booted quickly (30-40 seconds) but spent another 20-30 seconds with degraded performance while instance initialization completed in the background. Your application might start, but those first requests will be slow.
What Slows Down Boot Time?
Storage backend makes the biggest difference. Providers using local NVMe can snapshot and restore faster than those relying on network-attached SAN storage. Boot time also reveals how much a provider overcommits their hypervisors—if the host is thrashing, your instance waits in queue.
Network Latency Findings
From US East, DigitalOcean, Linode, and Vultr all averaged 0.5-1.5ms within the same datacenter region. Cross-region to US West added 65-70ms, which matches the speed of light in fiber.
Hetzner's Germany datacenter showed 80-90ms from US East, predictable for transatlantic routing. Their Finland location was 5-10ms slower.
OVHcloud had inconsistent routing. Some tests went direct; others bounced through Montreal or Paris even when testing to a US endpoint. Latency varied by 20ms between identical requests.
Contabo's network had the most jitter. Average latency looked acceptable, but the 95th percentile was 40-60ms higher than the mean. Packet loss was rare but TCP handshake time was unpredictable.
AWS Lightsail matched EC2 network performance—fast and consistent. Same for Google Cloud and Azure. When you're paying for their network engineering, you get it even on the cheap tiers.
Latency From Asia and Australia
If your users are in Asia, provider choice matters more. DigitalOcean, Linode, and Vultr have Singapore datacenters with good peering to the region. Latency from Australia to Singapore averaged 100-120ms.
Hetzner doesn't have an Asian presence yet. Expect 180-220ms from Sydney to Germany, which kills real-time application performance.
The big cloud providers have the most Asian locations, but their entry VPS tiers often aren't available in all regions. Check before you commit.
Disk I/O Performance
This is where the biggest gaps appeared.
DigitalOcean's Droplets with NVMe delivered 40-50K IOPS on random 4K operations. Read latency stayed under 0.5ms even under load.
Linode and Vultr were similar, 35-45K IOPS with low latency variance. These providers clearly use modern NVMe storage and don't oversell capacity.
Hetzner surprised me—60-70K IOPS on their entry tier. Their local NVMe backing combined with less aggressive overselling than competitors gave consistently fast disk access.
OVHcloud hit 20-30K IOPS with occasional stalls. Write latency spiked above 5ms during these stalls, suggesting shared storage with noisy neighbors.
Contabo managed only 5-10K IOPS. Their SSD storage is real, but SATA-based and clearly oversubscribed. Database workloads will struggle.
AWS Lightsail uses EBS, which is network-attached storage. That added latency means 8-12K IOPS at best, but performance was consistent. You get what you pay for, and it doesn't fluctuate.
Google Cloud and Azure's burst tiers gave 10-15K IOPS initially, then throttled hard after burning through burst credits. This is documented behavior, but it catches people off guard. Check your sustained performance specs, not peak.
Testing Disk I/O Yourself
Install fio and run this test:
sudo apt update && sudo apt install fio -y
fio --name=randwrite --ioengine=libaio --iodepth=16 --rw=randrw \
--rwmixread=70 --bs=4k --direct=1 --size=1G --numjobs=4 \
--runtime=60 --group_reporting
Look at the IOPS numbers and the latency percentiles. If p95 latency is more than 5x the average, you're on overloaded storage.
Price-Performance Breakdown
Cheapest isn't always worst. Hetzner delivered top-tier performance at a lower price than DigitalOcean or Linode. Their datacenter locations are limited, but if Europe works for your use case, they're hard to beat.
Contabo is cheap for a reason. Raw specs look good on paper, but the performance gaps mean you'll need a larger instance to match what you'd get elsewhere.
AWS Lightsail, Google Cloud, and Azure cost more than independent providers for equivalent specs, but you're paying for network quality and ecosystem integration. If you need to connect to other cloud services, the premium makes sense.
DigitalOcean and Linode sit in the middle—more expensive than Hetzner, less than the big clouds, with solid performance and better support than budget hosts.
What About CPU Performance?
I left CPU benchmarks out because they're misleading on shared VPS instances. You might get a fast Sysbench score one hour and half that the next hour when your neighbor spins up a compile job.
The metrics above—boot time, network, and disk—reveal how the provider manages shared resources. Fast consistent disk I/O means they're not overselling. Low network jitter means quality peering and uncongested uplinks. Quick boot times mean the hypervisor isn't overloaded.
Those infrastructure choices affect CPU performance too, but CPU benchmarks fluctuate too much to be useful for provider comparison.
Recommendations by Use Case
Development and staging environments: Hetzner if you're in Europe, Vultr or DigitalOcean otherwise. Boot time and cost matter more than peak performance.
Production web applications: DigitalOcean or Linode for the balance of performance and support. Their network quality and disk I/O handle traffic spikes well.
Database servers: Hetzner for the disk I/O. If you need US locations, Linode or Vultr. Avoid Contabo and the burst-limited cloud tiers.
Global audience: Use the big cloud providers and distribute across regions, or pick DigitalOcean/Vultr for their datacenter spread combined with better entry-tier performance than AWS Lightsail.
Tight budget: Hetzner first. If you need US datacenters, Vultr. Skip Contabo unless you're running services that don't touch disk and can tolerate latency variance.
Common VPS Performance Issues
Slow VPS performance isn't always the provider's fault. Check your end first:
- Full disk kills I/O. Run
df -hand clean up logs. - Memory pressure causes swapping. Check
free -hand upgrade if you're using swap heavily. - Misconfigured firewalls add latency. Every iptables rule is a lookup; keep your chains short.
- Outdated kernels miss performance fixes. Ubuntu 22.04 ships with 5.15; newer kernels improve NVMe performance.
- DNS resolution is often the culprit in "slow network" complaints. Test with IPs first.
If those check out and performance still lags behind what you saw in benchmarks, open a support ticket. Good providers will investigate noisy neighbors or migrate you to a healthier host.
Where to Start
Pick a provider based on your datacenter needs first, performance second. The fastest VPS in Europe doesn't help if your users are in Australia.
Once you've filtered by location, look at the disk I/O numbers. That's where the biggest performance gaps appear and where you'll feel it most in production.
Provision a trial instance and run the fio test above. Check boot time with a script. Ping from your users' locations. Your workload is unique; these benchmarks give you a starting point, but your own tests make the final call.
Don't chase peak performance specs. Consistent, predictable performance under load matters more than winning a single benchmark.