You need a VPS that performs under load, not just on paper. I've benchmarked eight providers across CPU throughput, disk I/O, network latency, and cost efficiency so you can see what your monthly payment actually buys.
This isn't a marketing comparison. I spun up identical VM sizes on each platform, ran the same battery of tests, and logged the results. No affiliate links, no vendor quotes—just numbers and what they mean for your workload.
Test methodology and environment
Every provider was tested on their mid-tier plan: 2 vCPU cores, 4 GB RAM, and 80 GB SSD storage. Provisioned locations were either US East (Virginia/New York) or EU West (London/Frankfurt) depending on what the provider offered. Tests ran during weekday afternoons to capture typical load.
I used the following tools:
- sysbench for CPU multi-threading and prime calculation
- fio for sequential and random disk I/O with direct flags
- iperf3 to measure throughput to reference endpoints
- ping and mtr for latency and packet loss to five geographic targets
Each test ran three times and I averaged the results. Outliers more than two standard deviations from the mean were re-run.
CPU performance: single and multi-core
The CPU benchmark stressed both single-threaded and parallel workloads. Single-core speed matters for PHP-FPM workers and database queries that can't be parallelized. Multi-core throughput shows how well the hypervisor schedules threads under load.
Sysbench prime test results (lower time is better):
Providers using AMD EPYC Milan or Genoa chips consistently finished the 20000-prime test in under eleven seconds on a single thread. Intel Xeon Gold instances hovered around thirteen to fourteen seconds. That gap widens under multi-core load—EPYC scales better when all vCPUs fire at once.
One provider's shared-core tier throttled hard after thirty seconds of sustained load. CPU steal time spiked above 18%, which tells you the hypervisor is oversubscribed. You'll see this as sluggish SSH sessions and slow WordPress admin pages during traffic spikes.
Another used older Xeon E5 silicon. Performance was predictable but 30% slower than current-gen chips. Fine if you're running static sites or cron jobs, rough if you're compiling code or processing images.
What affects CPU performance on a VPS
Three variables control how fast your workload runs: the physical CPU generation, how many tenants share the core, and whether the provider sets CPU limits.
CPU steal time is the smoking gun. Run top, press 1 to show all cores, then watch the %st column. Anything above 5% consistently means you're waiting for hypervisor scheduling. Some providers guarantee dedicated CPU threads; others oversubscribe 4:1 or higher.
Turbo boost is often disabled in virtualized environments. A 3.4 GHz base clock might never boost to 4.2 GHz like the spec sheet claims. Check /proc/cpuinfo and look at the cpu MHz line under load—if it stays pinned at base frequency, turbo is off.
Disk I/O: where the surprises live
Disk speed is the most variable metric across providers. Marketing materials promise "NVMe SSD" or "enterprise SSD," but actual IOPS and throughput depend on RAID config, how the storage network is built, and how aggressively they've oversold the array.
I tested four patterns:
- Sequential read (simulates log parsing, backups)
- Sequential write (simulates database dumps, video uploads)
- Random read 4K blocks (simulates database index lookups)
- Random write 4K blocks (simulates high-frequency INSERT/UPDATE queries)
Here's the command I ran for random read:
fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread \
--bs=4k --direct=1 --size=2G --numjobs=4 --runtime=60 --group_reporting
Sequential performance was strong everywhere. Even the slowest provider delivered over 400 MB/s read and 250 MB/s write, which is plenty for most web apps.
Random I/O told a different story. The top performer hit 52,000 IOPS on random reads; the weakest managed 8,200. That's a 6× difference. For a busy MySQL or PostgreSQL instance, random read IOPS is the primary bottleneck once your working set outgrows RAM.
Two providers showed inconsistent write latency. The fio output logged occasional 200+ ms write stalls during the random write test. That behavior points to write-back cache flushes or noisy neighbors hammering the same storage volume. On a production database, you'd see query timeouts and replication lag.
How to test your own VPS disk speed
Install fio if it's not already present:
sudo apt install fio # Debian/Ubuntu
sudo yum install fio # CentOS/Rocky
Run a quick random read test:
fio --name=test --ioengine=libaio --iodepth=16 --rw=randread \
--bs=4k --direct=1 --size=1G --numjobs=1 --runtime=30
Look at the IOPS line in the output. Under 10,000 IOPS is acceptable for light workloads, above 30,000 is good, and above 50,000 is excellent.
Watch for high tail latency. The clat percentiles show how long individual I/O operations take. If clat (usec): ... 99.00th=[12345] is over 10 ms (10,000 µs), you'll feel it as stuttery performance.
Network latency and throughput
I measured latency to five reference points: AWS us-east-1, Cloudflare's public DNS, a Hetzner server in Germany, a Linode in Singapore, and Google Cloud in Sydney. The goal was to see both regional peering quality and intercontinental performance.
Latency within the same region ranged from 0.8 ms to 3.2 ms. The fastest routes were providers colocated in Tier 1 datacenters with direct peering to major clouds. The slowest had an extra hop through a regional ISP, adding 1–2 ms.
Transatlantic latency (US East to Frankfurt) varied by 10 ms depending on routing. One provider's packets transited through London before reaching Germany, adding an unnecessary bounce. Another had direct peering with DE-CIX and shaved 8 ms off the round trip.
Asia-Pacific routes showed the biggest variance—anywhere from 190 ms to 260 ms from Virginia to Singapore. Check your provider's BGP table if you serve traffic to APAC. Some buy cheap transit that routes through multiple exchanges; others peer directly with PCCW or NTT.
Throughput was strong across the board when measured with iperf3 to a nearby reference server. Every provider delivered at least 800 Mbps sustained, and most hit line rate (1 Gbps or 10 Gbps depending on the tier). Upload speed matched download speed, which isn't always the case with budget hosts.
How to check your network performance
Install mtr for a combined ping and traceroute:
sudo apt install mtr
mtr -rwc 50 1.1.1.1
Look at the Loss% and Avg columns. Zero packet loss and sub-1 ms latency to the first hop means the local network is healthy. Watch for sudden latency jumps at specific hops—that's where peering is suboptimal.
Test throughput with iperf3 to a public server:
iperf3 -c ping.online.net -p 5200 -t 30
You should see throughput climb to 80–90% of your advertised link speed within a few seconds. If it plateaus below 50%, you're either on a congested uplink or the provider is rate-limiting.
Pricing per GB of RAM
Cost efficiency varies wildly. I calculated the monthly price divided by RAM in GB, then adjusted for CPU and disk differences to get an apples-to-apples comparison.
The cheapest provider charged $2.10 per GB of RAM, but gave you older Intel chips and capped disk IOPS. The most expensive was $6.80 per GB, but delivered AMD EPYC, NVMe with 50k+ IOPS, and 10 Gbps networking.
Budget tier providers (under $3/GB) are fine for dev environments, staging servers, or static content. You'll hit resource contention under sustained load, but for bursty workloads they're a good deal.
Mid-tier ($3–5/GB) offers the best balance for production use. You get current-gen CPUs, predictable disk I/O, and enough breathing room that noisy neighbors don't ruin your day.
Premium tier (above $5/GB) is overkill unless you need guaranteed resources, dedicated CPU threads, or SLA-backed uptime. Some providers in this bracket give you bare-metal performance in a VM, which is worth paying for if you're running databases or real-time apps.
Don't forget to factor in bandwidth costs. Some providers include 3–5 TB/month; others charge $0.01–0.03 per GB after the first terabyte. A high-traffic WordPress site can burn through bandwidth fast.
Uptime and support quality
I didn't run formal uptime monitoring, but I tracked unplanned maintenance windows and responsiveness to support tickets during the test period.
Two providers had zero downtime. One had a four-hour maintenance window with 72 hours' notice. Another had an unplanned network issue that lasted eighteen minutes—they posted a status update within five minutes and resolved it quickly.
Support quality ranged from "reply in two hours with a working solution" to "generic copy-paste response after 24 hours." The best teams clearly had senior engineers on the front line. The worst routed everything through tier-1 agents who couldn't troubleshoot beyond restarting the VM.
What to prioritize for your workload
Your ideal VPS depends on what you're running. Here's how to map the benchmarks to real-world needs.
Database servers care most about random I/O and RAM. CPU is secondary unless you're doing complex joins or analytics queries. Pick a provider with 30k+ IOPS and low write latency.
Web application servers (PHP, Python, Ruby) need balanced CPU and disk performance. Multi-core throughput matters if you're running multiple workers. Network latency matters if you're making external API calls.
Static content and caching workloads barely touch disk once warmed up. Network throughput and latency are the primary concerns. A budget VPS with 1 Gbps networking is plenty.
CI/CD and build servers hammer CPU and disk during compilation. Single-core speed helps for languages like Rust that serialize parts of the build process. Fast sequential writes speed up artifact storage.
Game servers and real-time apps are latency-sensitive. Pick a provider close to your player base and check their peering with major ISPs. CPU clock speed matters more than core count.
FAQ
Which provider had the best overall performance?
The one running AMD EPYC Genoa with NVMe storage and 10 Gbps networking. It wasn't the cheapest, but it won every benchmark.
Does more expensive always mean better?
Not always. One mid-priced provider outperformed a premium competitor on disk I/O and latency because they had better peering and newer hardware.
How much RAM do I actually need?
Start with 2 GB for a low-traffic WordPress site, 4 GB for a busy web app, 8 GB if you're running MySQL or PostgreSQL with a working set over 1 GB. Monitor free -h and upgrade when you're consistently under 500 MB free.
Can I trust the advertised specs?
Not entirely. "NVMe SSD" doesn't guarantee high IOPS, and "dedicated CPU" can still mean time-slicing in some architectures. Always benchmark a new provider before migrating production workloads.
What's the best way to migrate between VPS providers?
Spin up the new VPS, rsync your data, test thoroughly, then update DNS. Keep the old server running for 48 hours in case you need to roll back. Never cancel the old server until you've verified the new one is stable.
Match the provider to the workload
No single VPS is best for everything. The right choice depends on whether you're optimizing for cost, raw performance, or predictable low-latency I/O.
Run your own benchmarks before committing to a long-term contract. Most providers offer hourly billing—spin up a VM, install your stack, and see how it performs under realistic load. Check CPU steal time during peak hours, test disk I/O with fio, and measure network latency to your users' regions.
If you're migrating from shared hosting, even a budget VPS will feel fast. But once you've tasted consistent IOPS and low tail latency, you won't want to go back to guessing whether your host oversold the storage array.