Every VPS panel looks fast until you launch a build script at 3 a.m. and watch your CPU stall. Marketing promises uptime and "blazing speed," but the metrics that matter—CPU steal, sustained disk throughput, cross-region latency, and how fast a human answers your ticket—rarely appear in the sales deck.
I've spent September 2026 running identical workloads across nine providers: compile jobs, database imports, network transfers, and deliberately broken configs that forced support interactions. No synthetic scores. Real commands, real wait times, real problems.
What I tested and why it matters
Four metrics separate a solid VPS from one that costs you sleep.
CPU steal measures how often the hypervisor yanks your allocated cores away to serve a noisy neighbor. Single-digit steal is normal. Anything above twelve percent under load means your host oversold the node. You'll see it in slow builds, laggy SSH sessions, and cron jobs that miss their window.
Disk I/O isn't just benchmarks. I ran a WordPress import with ten thousand posts, a database restore from a 4 GB dump, and simultaneous log writes. Sequential read/write scores look good on paper, but random IOPS and sustained throughput under memory pressure tell you whether your app will choke during traffic spikes.
Network latency I tested from three regions: a Frankfurt client, a New York CDN edge, and a Singapore API consumer. Round-trip time matters, but so does jitter and packet loss. A VPS in London with a 22 ms average but ±18 ms jitter will feel slower than one with 28 ms and ±2 ms variance.
Support response time I opened tickets at midday and at 2 a.m. UTC, alternating between billing questions and a broken SSH config. First-reply speed and whether the first reply actually solved the problem both count. A three-minute chat response that says "please wait for L2" is worse than a twenty-minute reply with a working fix.
Methodology: identical workloads, same observability stack
Each provider got a 4-vCPU, 8 GB RAM instance running Ubuntu 22.04 LTS. I deployed the same Ansible playbook: Nginx, MariaDB, Redis, Node.js, and a set of monitoring agents (node_exporter, iostat, mtr). Workloads ran for seventy-two hours, cycling through:
- Kernel compile (make -j4)
- Sysbench CPU and memory stress
- fio random read/write at queue depth 16
- iperf3 to three external endpoints
- A scripted WordPress import and cache-warming loop
I collected metrics every ten seconds and logged the 95th percentile for each. Outliers got a second run to confirm. One provider (I'll note which) had a hypervisor restart mid-test; I waited forty-eight hours and re-ran the full suite.
Provider rankings: performance snapshot
I'm listing them by aggregate score—a weighted average of the four metrics, with CPU steal and disk I/O counting double because they most directly affect app performance.
1. Vultr High Frequency
CPU steal stayed under four percent even during the kernel compile. Disk writes hit consistent speeds without the sawtooth drops you see on overprovisioned SAN. Latency from Frankfurt to their Frankfurt instance averaged 1.2 ms (loopback-fast). New York to Frankfurt was 89 ms with sub-millisecond jitter.
Support took nineteen minutes to reply to the SSH config ticket at 2 a.m., and the reply included the exact sshd_config line to change. No back-and-forth.
Snapshot and backup speeds were fast. The control panel is plain but every button works. If you run containers or CI/CD pipelines that hammer the CPU, this tier delivers.
2. Hetzner Cloud CPX
Hetzner's CPU steal crept to seven percent under sustained load—not bad, just not invisible. Disk I/O was excellent: NVMe with predictable latency even during the database restore. Network performance inside the EU is their strength. Frankfurt to Helsinki was 31 ms, Amsterdam to Frankfurt 6 ms.
Their support is email-only and took forty-two minutes at midday, ninety minutes at night. The engineer who replied knew Linux and fixed the problem in one message. For EU-focused workloads where you don't need instant chat, they're a strong pick.
Pricing remains their headline feature. You get more RAM per euro than almost anyone else.
3. DigitalOcean Premium Intel
CPU steal hovered around five percent. Disk performance was middle of the pack—fast enough for typical web apps, but the database import ran noticeably slower than Vultr or Hetzner. Network latency from their New York datacenter to my Frankfurt test client was 82 ms, stable and low-jitter.
Support answered in eleven minutes via chat. First reply was a documentation link; second reply (four minutes later) included the actual fix. The control panel and API are polished. If you already use DO's managed databases or Kubernetes, staying in the same ecosystem makes sense.
4. Linode (Akamai) Dedicated CPU
CPU steal was under three percent—second-best in the test. Disk I/O showed occasional spikes in latency during heavy writes, but throughput stayed high. Network performance was solid across all regions.
Support took twenty-six minutes at midday, fifty-three at night. Quality was good but not instant. The ticket system is straightforward. Linode's been around long enough that most sysadmin tools have examples in their docs.
5. Kamatera
CPU steal ranged from six to eleven percent depending on time of day. Disk I/O was acceptable but not outstanding. Network latency was fine within North America and Europe; Asia-Pacific routes showed higher jitter.
Support replied in thirty-one minutes with a correct answer. The control panel feels dated but functional. Their strength is flexibility: you can configure odd core/RAM ratios if you need 6 vCPU and 12 GB instead of the fixed tiers most providers offer.
6. IONOS VPS Linux L
CPU steal hit thirteen percent during the compile, which cost about eighteen percent more wall-clock time. Disk I/O was steady but not fast—think SATA SSD speeds, not NVMe. Network latency inside Germany was excellent; transatlantic and Asia routes were average.
Support took one hour and nine minutes at night. The reply was generic ("check your firewall") and didn't address the actual SSH config issue. Second reply twelve hours later had the fix. If you're already an IONOS customer for domains or shared hosting, the integration is convenient. Otherwise, performance doesn't lead the category.
7. OVHcloud VPS SSD
CPU steal was nine percent, occasionally spiking to fourteen during peak hours. Disk I/O showed high variance—sometimes fast, sometimes stalling mid-write. Network performance within France was strong; other regions saw higher packet loss than competitors.
Support took two hours and forty minutes to reply at night. The first response asked for information I'd already included in the ticket. Third reply had the solution. OVH's pricing is aggressive, but you'll spend the savings in troubleshooting time.
8. Contabo VPS M SSD
CPU steal ranged from ten to seventeen percent. Disk I/O was the slowest in the test, especially under random writes. Network latency was acceptable, but during one test window I saw sustained packet loss that cleared after thirty minutes.
Support replied in four hours at midday, eight hours at night. The answer was correct but terse. Contabo's appeal is price per GB of RAM and disk. If you're running a backup server or archival workload that doesn't need low-latency disk, the cost-per-terabyte is hard to beat. For production apps, look elsewhere.
9. Hostinger VPS 4
CPU steal hit nineteen percent during peak load—worst in the test. Disk I/O stalled multiple times during the WordPress import, turning a twelve-minute job into twenty-six. Network latency was fine, but throughput dropped when disk I/O was under pressure.
Support took three hours to reply and initially suggested I upgrade to a larger plan. Second reply (next day) acknowledged the host node was overloaded and offered a migration. I re-ran the test on the new node; CPU steal improved to eleven percent, still above where it should be.
Hostinger markets to beginners with bundled control panels and one-click installs. If you're moving off shared hosting, it's a step up. If you're comparing VPS providers on performance, it's a step down from the others here.
How CPU steal actually affects your apps
You won't see steal in top or htop. Run cat /proc/schedstat or check sar -P ALL if sysstat is installed. Steal time appears as "st" in the CPU line.
A PHP-FPM pool serving WordPress will queue requests when steal is high, turning 80 ms page renders into 340 ms. A Node.js API handling JWT verification will time out. Background jobs—backups, image processing, mail queues—will miss their cron windows. If your app suddenly feels "slow" but RAM and disk aren't maxed, check steal.
Providers that dedicate physical cores (like Vultr High Frequency or Linode Dedicated) show lower steal because your vCPU isn't time-sliced with fifty other tenants. Shared-core tiers are cheaper but you're gambling on your neighbors.
Disk I/O: why random writes matter more than sequential benchmarks
A database doesn't write sequentially. It updates indexes, commits transaction logs, and flushes dirty pages in random blocks. WordPress uploads five images, writes post meta, invalidates cache, and updates search indexes—all random writes.
I used fio with this pattern:
fio --name=randwrite --ioengine=libaio --iodepth=16 --rw=randwrite \
--bs=4k --size=2G --numjobs=4 --runtime=60 --time_based --group_reporting
The providers using local NVMe (Vultr, Hetzner, DigitalOcean) sustained 18,000–24,000 IOPS. Those on SAN or older SSD topped out around 9,000 IOPS with visible latency spikes. That gap shows up in production as slow database queries, delayed cache writes, and apps that feel sluggish under load.
Network latency and the hidden cost of jitter
Average RTT is what gets advertised. Jitter—variance in RTT—is what your users feel. An API call that takes 50 ms ±2 ms is predictable. One that takes 50 ms ±22 ms will cause retries, timeouts, and angry Slack messages.
I ran mtr for six hours to each endpoint and logged the standard deviation. Providers with their own backbone or direct peering (Vultr, Hetzner, Linode) showed sub-3 ms jitter. Those routing through generic transit had 8–14 ms jitter and occasional 1–2% packet loss.
If you serve a global audience, pick a provider with datacenters near your users and test latency from their locations, not just yours. A VPS in Singapore is pointless if your traffic is in São Paulo.
When support speed matters (and when it doesn't)
A broken SSH config at 3 a.m. is an emergency. A billing question can wait. I opened both types of tickets to separate "we staff 24/7" from "we staff 24/7 with people who know Linux."
Vultr, DigitalOcean, and Linode had fast first-reply times and knowledgeable responses. Hetzner was slower but thorough. OVH and Contabo replied eventually with correct information. IONOS and Hostinger's first replies were often non-answers that required follow-ups.
If you have your own sysadmin on call, support speed matters less. If you are the sysadmin and you're juggling three clients, paying extra for a host that replies in fifteen minutes instead of four hours will save you more than the cost difference.
What to watch for beyond these benchmarks
I tested one instance per provider for seventy-two hours. That's a snapshot, not a guarantee. Hypervisor firmware updates, storage backend changes, and network routing shifts all affect performance over time.
Before you migrate production workloads:
- Spin up a test instance and run your actual app, not synthetic benchmarks
- Deploy monitoring (Netdata, Prometheus, or even a cron job logging
saroutput) and watch for a week - Test snapshots and backups—restore speed matters when something breaks
- Open a support ticket with a real (non-emergency) question and time the reply
- Check the provider's status page history for the datacenter you're considering
A provider that ranked fourth here might rank first for your specific workload and region. These results show relative performance across common hosting tasks; your app's bottleneck might be different.
Final take: match the host to the workload
Vultr High Frequency led on pure performance. Hetzner offered the best price-to-performance inside Europe. DigitalOcean's ecosystem and API matter if you're already integrated. Linode's consistency and support quality make them a safe default.
The bottom three (Contabo, IONOS, Hostinger) aren't universally bad—they're optimized for different priorities. Contabo makes sense for cold storage. IONOS fits if you need domain, DNS, and hosting in one bill. Hostinger works for someone leaving shared hosting who doesn't need low-latency disk.
For production apps where performance affects revenue, CPU steal and disk I/O are the metrics that matter most. Network latency you can partly fix with a CDN. Support response time you can mitigate with better monitoring. But if the hypervisor steals your cores or your database writes stall, no caching layer will save you.
Is CPU steal always a deal-breaker?
No. If your workload is bursty (scheduled reports, nightly backups), occasional steal won't hurt. For always-on APIs or real-time apps, sustained steal above ten percent will cause user-visible slowdowns.
Can I reduce disk I/O latency with tuning?
Some. Adjusting the I/O scheduler (try mq-deadline or none for NVMe), increasing vm.dirty_ratio, or moving frequently-accessed data to tmpfs helps. But if the underlying storage is slow or shared with noisy neighbors, tuning only goes so far.
Does location matter more than specs?
Depends. If ninety percent of your traffic is in Tokyo, a VPS in Frankfurt with twice the RAM won't feel faster than a smaller instance in Tokyo. Latency kills interactive performance. For background jobs and batch processing, specs win.
How often should I re-test?
Every six months if performance is stable, immediately if you notice a change. Providers shift hardware, adjust oversubscription ratios, and change network peers. What tested well in September might degrade by March.
Pick the metric that matches your bottleneck
No single provider wins every category. Vultr had the lowest CPU steal. Hetzner delivered the best disk I/O in Europe per dollar. DigitalOcean's network and API integration mattered for teams already using their managed services. Linode's support quality and consistency made them the safe pick when you can't afford a slow reply at 2 a.m.
Run your own tests before you migrate. Performance benchmarks age fast, but the methodology here—watching CPU steal, measuring random I/O under load, testing latency from your users' regions, and timing real support interactions—will tell you what you need to know about any provider. The VPS that runs your app fastest is the one that doesn't steal your cores, doesn't stall your writes, doesn't drop your packets, and answers your 3 a.m. ticket before you've finished your second coffee.