I spent three months testing nine VPS providers to answer one question: which one delivers consistent speed when you actually need it? Not marketing promises—real uptime percentages, disk I/O under load, and network round-trip times measured from four continents.
This isn't a feature list or a spec sheet comparison. I provisioned identical 4 GB RAM, 2 vCPU instances on each platform, installed the same LEMP stack, and ran the same workload tests every six hours for ninety days. The results surprised me.
What I tested and why it matters
Three metrics tell you if a VPS will hold up under production traffic: uptime (can users reach your site?), disk IOPS (can your database keep up?), and network latency (how fast do requests round-trip?). I skipped CPU benchmarks because modern hypervisors share cores in ways that make synthetic tests meaningless. Real-world performance under your actual workload is what counts.
Each provider got the same treatment. Ubuntu 22.04 LTS, Nginx 1.24, MariaDB 10.11, PHP 8.2. I ran a WordPress site with WooCommerce and fifty test products, hitting it with a steady 50 requests per second from five global locations. Every six hours, an automated script logged response times, ran fio disk tests, and pinged from monitoring nodes in Frankfurt, Singapore, New York, São Paulo, and Sydney.
No provider knew they were being tested.
The nine providers in this test
I picked platforms you'll actually consider: DigitalOcean, Linode (now Akamai), Vultr, Hetzner, OVHcloud, Contabo, Kamatera, UpCloud, and Cloudways (which resells DigitalOcean and Vultr instances with a management layer). All offer hourly billing, root access, and API provisioning. Price range was $20 to $48 per month for the 4 GB tier.
Some have data centers everywhere. Others focus on Europe or North America. I picked the closest location to Frankfurt for the primary instance since that's where most of my clients' audiences sit, but I also spun up US East and Singapore instances for the latency tests.
Uptime: who stayed online
Ninety days, monitored every five minutes. That's 25,920 checks per instance.
The top tier—DigitalOcean, Linode, and UpCloud—logged zero unplanned downtime. Not a single five-minute window where the HTTP check failed. Vultr had one fourteen-minute blip in September that their status page attributed to hypervisor maintenance in the Frankfurt region. Hetzner had two brief outages, both under ten minutes, both during off-peak European hours.
OVHcloud dropped three times, the longest for forty-two minutes. Contabo had five separate incidents, including one Saturday morning stretch of three hours where the instance was unreachable. Their support blamed a "network loop" in the data center. Kamatera and Cloudways (on the DigitalOcean backend) matched their underlying infrastructure.
If you're running an e-commerce site or a SaaS dashboard, those multi-hour outages add up. Even if the monthly average looks fine at 99.8%, a three-hour Saturday outage is three hours of lost revenue.
Disk IOPS: the hidden bottleneck
Your VPS might have NVMe storage on paper, but if it's oversubscribed or the hypervisor throttles I/O, your database will crawl. I used fio with a 4 GB test file, random 4K read/write, queue depth 32. This simulates what happens when MariaDB is handling concurrent queries.
UpCloud crushed this test. Consistent 45,000+ read IOPS, write IOPS above 15,000. Their MaxIOPS product line is engineered for exactly this. DigitalOcean and Linode came in around 30,000 read / 10,000 write, very stable across the ninety days. Vultr was slightly lower but consistent.
Hetzner's numbers looked great on average—28,000 read IOPS—but every few days they'd drop to 8,000 for an hour or two. Classic noisy neighbor problem. Their cloud instances share physical NVMe drives across multiple VMs, and when someone else hammers the disk, you feel it.
Contabo barely hit 5,000 read IOPS most of the time. OVHcloud fluctuated wildly, anywhere from 12,000 to 3,000. If your application does heavy database writes or serves a lot of uncached content, you'll notice. Kamatera was middle of the pack, around 18,000 read IOPS with occasional dips.
Here's the thing: if your site loads static assets from a CDN and your database queries are well-indexed, you won't max out disk I/O on any of these. But the moment you run a WooCommerce import, a WordPress plugin scan, or a log analysis script, the difference shows up.
Network latency: round-trip times from five continents
I pinged every instance from monitoring nodes in Frankfurt, New York, Singapore, São Paulo, and Sydney every six hours and logged the median round-trip time. Frankfurt numbers were all under 5 ms—too close to call. The differences appeared when you looked globally.
From New York to the Frankfurt instances, DigitalOcean and Linode averaged 85 ms. Vultr and UpCloud were 88 ms. Hetzner clocked 82 ms, which makes sense given their deep peering in Europe. OVHcloud hit 95 ms, and Contabo was all over the map, anywhere from 90 to 140 ms depending on the time of day.
From Singapore, UpCloud routed fastest at 168 ms average. DigitalOcean and Linode were 175 ms. Hetzner was slower at 195 ms because their European peering doesn't help with Asian routes. Contabo again struggled, often exceeding 220 ms.
São Paulo and Sydney showed similar patterns: DigitalOcean, Linode, Vultr, and UpCloud clustered within 10 ms of each other, while the budget-tier providers (Contabo, OVHcloud) lagged by 30-50 ms.
Those milliseconds matter if you're serving a global audience. A 50 ms difference in round-trip time translates directly to 50 ms added to every uncached API call or database query your frontend makes. Multiply that by a chatty JavaScript app making twenty requests per page load, and users notice.
Real-world WordPress performance
Benchmarks are one thing. Actual page load time under traffic is another.
I kept the same WordPress + WooCommerce site running on each instance for the full ninety days, hitting it with a constant 50 requests per second from a mix of global locations. No caching plugin, no CDN—just Nginx with basic FastCGI caching and MariaDB with default my.cnf tuning.
UpCloud served pages in an average of 220 ms (time to first byte). DigitalOcean and Linode were neck and neck at 240 ms. Vultr came in at 255 ms. Hetzner was 270 ms on average but spiked to 600+ ms during those I/O throttle windows. OVHcloud averaged 310 ms with frequent spikes above half a second. Contabo rarely got below 400 ms and often climbed past a full second during peak European hours.
Kamatera sat at 280 ms average, respectable but not outstanding. Cloudways added a management layer that introduced another 30-40 ms of overhead compared to running directly on DigitalOcean, though their automatic caching and staging tools might be worth that trade-off if you're not comfortable managing a server yourself.
For a WooCommerce shop with 500 daily visitors, the difference between 220 ms and 400 ms time to first byte is the difference between snappy and sluggish. Users abandon carts when pages feel slow, even if they load in under two seconds total.
Support response times (when things break)
I opened a ticket with each provider midway through the test period, reporting a fake issue: "Intermittent packet loss to IP address X." This wasn't a real problem—I just wanted to see how fast they responded and whether the first reply was a human or a bot.
DigitalOcean replied in eleven minutes with a human technician who asked for an MTR report. Linode responded in eighteen minutes, also human, also asking for diagnostic data. UpCloud took twenty-three minutes. Vultr came back in thirty-one minutes. All four gave me engineers who clearly understood the question.
Hetzner's ticket sat for two hours before an automated reply asked me to run a traceroute. A human followed up four hours later. OVHcloud took nine hours to send an automated response, then another six hours for a human. Contabo's first reply arrived nineteen hours later, a generic "we're investigating" message. Kamatera responded in forty minutes, middle of the pack.
Cloudways was fastest at seven minutes, but that's because you're paying extra for their managed support layer. They don't own the infrastructure, so complex network issues get escalated to the underlying provider anyway.
If your site goes down at 3 a.m. and you need help, response time matters. An eleven-minute wait versus a nine-hour wait is the difference between a minor blip and a full business day of downtime.
Price versus performance: what you actually get
The 4 GB instances I tested ranged from $20 (Contabo) to $48 (UpCloud's MaxIOPS tier). You get what you pay for, but not always linearly.
Contabo's price is low because they oversubscribe aggressively. You'll get 4 GB of RAM and 2 vCPU cores, but you're sharing physical resources with far more neighbors than on DigitalOcean or Linode. That's fine for a staging server or a personal blog. It's not fine for a production store.
Hetzner offers better value than Contabo at $25 per month, and their performance is much closer to the premium tier—when it's stable. If you can tolerate occasional I/O throttling and you're serving a primarily European audience, they're a solid pick.
DigitalOcean, Linode, and Vultr all price around $32-36 for the same spec. Performance was nearly identical in my tests, so pick based on which control panel you prefer or which one has a data center closest to your users.
UpCloud costs more, but if disk I/O is your bottleneck—large database imports, heavy logging, real-time analytics—the extra $12-16 per month pays for itself in performance. For a typical WordPress site, you won't notice the difference.
Which provider should you pick?
If you need rock-solid uptime and fast support, go with DigitalOcean or Linode. Both had zero downtime in my ninety-day test and responded to tickets in under twenty minutes. Their global network handled latency tests well from every continent. You won't be disappointed.
If disk I/O matters more than anything else—maybe you're running a high-traffic WooCommerce site with frequent inventory updates or a logging-heavy application—UpCloud is the pick. Their MaxIOPS instances delivered 50% better IOPS than the next competitor, consistently.
If you're on a tight budget and serving a European audience, Hetzner gives you most of the performance of the premium tier at a lower price. Just be ready for occasional I/O slowdowns during peak hours, and don't expect sub-hour support response times.
Avoid Contabo for anything user-facing. Five outages in ninety days and single-digit thousand IOPS is not acceptable for a production site. Their price is tempting, but downtime costs more than the monthly savings.
OVHcloud sits in an awkward middle ground—not cheap enough to justify the performance gaps, not fast enough to compete with DigitalOcean or Linode. I'd skip them unless you have a specific reason to use their European data centers.
Cloudways makes sense if you want managed WordPress hosting and don't want to SSH into a server. You're paying extra for their dashboard, staging environments, and automatic backups. But you're also adding latency and giving up some control. If you're comfortable with the command line, provision directly with DigitalOcean or Vultr and keep the savings.
What to watch out for after you provision
Getting a VPS is the easy part. Keeping it fast takes ongoing work.
Set up monitoring on day one. Use something simple like UptimeRobot or Hetrix Tools to ping your site every five minutes and alert you when it goes down. Don't wait for a customer to tell you your site is offline.
Tune your database. The default MariaDB or MySQL configuration assumes you have gigabytes of RAM to spare. On a 4 GB VPS running a web server, PHP, and a database, you'll want to set innodb_buffer_pool_size to around 1.5 GB and adjust max_connections based on your traffic. Run mysqltuner once a week and follow its suggestions.
Watch your disk space. I've seen WooCommerce logs fill a 50 GB root partition in two weeks. Set up a cron job to rotate and compress old logs. Use ncdu to find what's eating space when you get a low-disk alert.
Enable automatic security updates for your OS packages. Run unattended-upgrades on Ubuntu or the equivalent on your distro. You don't want to manually SSH in every week to patch OpenSSH.
Back up your data offsite. Most providers offer automated snapshots, but those live in the same data center as your instance. Use rclone to push nightly backups to a different provider's object storage—Backblaze B2 or Wasabi are cheap and reliable.
How much RAM do I actually need for a WordPress site?
For a basic blog with a few plugins and light traffic, 2 GB is enough. A WooCommerce store or a membership site with lots of plugins needs at least 4 GB. If you're running multiple sites on one VPS or you get sudden traffic spikes, go for 8 GB. RAM is the first bottleneck you'll hit when traffic climbs.
Can I trust the 99.9% uptime claims in the sales pages?
Some providers hit it, some don't. In my ninety-day test, DigitalOcean, Linode, and UpCloud had zero downtime, which is well above 99.9%. Contabo had five outages totaling around five hours, which works out to about 99.3%. Always check third-party monitoring reports or run your own tests.
Do I need a managed VPS or can I handle it myself?
If you're comfortable with the Linux command line, SSH, and basic server administration, you don't need managed hosting. Provisioning a LEMP stack takes an hour if you follow a guide. If the idea of editing an Nginx config file or restarting MySQL makes you nervous, a managed option like Cloudways or a provider's managed tier is worth the extra cost.
How do I know if my VPS is slow because of my code or the provider?
Install htop and watch CPU and memory usage while your site is under load. If CPU is pinned at 100%, your application is the bottleneck—optimize your code or upgrade your plan. If CPU is low but disk I/O wait is high (the red bar in htop), your storage is the bottleneck. Run the fio disk test I mentioned earlier and compare to the provider's advertised specs. If network latency is the issue, use mtr to trace the route and see where packets are delayed.
What to check first when performance drops
Your VPS was fast last month and now it's not. Start here.
Check disk space with df -h. A full root partition will grind everything to a halt. If / is above 90%, find what's using space with du -sh /* and start deleting logs or old backups.
Restart your web server and database. Sometimes PHP-FPM or MySQL just needs a kick. Run systemctl restart nginx php8.2-fpm mariadb and see if performance improves.
Look at your database slow query log. Enable it in /etc/mysql/mariadb.conf.d/50-server.cnf with slow_query_log = 1 and long_query_time = 2. Any query taking more than two seconds will get logged to /var/log/mysql/slow.log. Optimize those queries or add indexes.
Check your access logs for traffic spikes or bot attacks. Run tail -f /var/log/nginx/access.log and watch for patterns. If you see the same IP hammering your site hundreds of times per minute, block it with ufw deny from <IP> or set up rate limiting in Nginx.
If none of that helps, your provider might be having infrastructure issues. Check their status page and open a support ticket with specific details: "TTFB increased from 200 ms to 800 ms starting October 10, no changes to site code or traffic."
Performance issues are rarely mysterious. They leave traces in logs, in resource usage graphs, and in your monitoring alerts. Dig into the data before you blame the provider or assume you need to migrate.