You have disk space allocation, a certain number of accounts you can create, some reassuring logos about security, and a control panel you already know. Some hosts even give you unlimited everything for a low monthly fee. Easy decision, right?
But here’s the catch: buying a reseller plan is a bit like buying a car without looking under the bonnet. From the outside, two cars might both look shiny, both come with four wheels and a steering wheel, and both promise to get you from A to B. But one is a modern electric - efficient, powerful, built with safety systems that keep you protected - while the other is a 15-year-old diesel with a loose exhaust, no airbags, and a worrying rattle. They’ll both move - but one does it smoothly and reliably, while the other strains and leaves you far more likely to end up stranded or in a crash.
That’s what I wanted to explore here. Because when resellers tell me another host looks cheaper, what they’re really asking (without realising it) is: what’s under the hood?
I realised that at Kualo we don’t do enough to explain why our platform is so much better than at other hosts.
So I went digging.
When a customer asked me this recently, I got myself a test account on the proposed competitor’s platform and ran some benchmarks. Nothing fancy - just the basic stuff that really matters for WordPress, WooCommerce, Magento and the kinds of sites you and I deal with every day.
On paper, their offering looked fine. But once you lift the lid, it becomes obvious that “unlimited” isn’t really unlimited, the server is dangerously under-resourced, and the hidden trade-offs in security and performance add up fast.
The thing is, you won’t spot any of that from the outside. But servers don’t run on marketing taglines - they run on CPUs, RAM, disk and security layers. And unless you know how to look under the hood, you can’t tell whether you’re getting a finely tuned machine or one that’s poorly configured and already straining. Most resellers don’t make that comparison because they don’t know how.
We do, and what we found here was eye-opening.
This post is my attempt to walk you through that analysis in plain English.
I’ll show you where the big differences are, why they matter in the real world, and how all of this connects back to what your clients actually care about: speed, reliability, and peace of mind.
Why Benchmarks Matter
Benchmarks are a bit like giving the engine a quick rev while the car’s still in the driveway. They don’t tell you everything about how it’ll handle on the motorway in the rain, but they give you a clear sense of what’s under there: how powerful it is, how quickly it responds, and whether it’s going to struggle once things get demanding.In hosting, the “engine” is really just two things:
- How quickly the server can execute PHP code (because WordPress, WooCommerce, Magento — all of them are basically big piles of PHP), and
- How quickly it can run database queries (because every page load, product search, or checkout pulls data from MySQL).
Now, here’s the interesting part: websites in the real world aren’t neat, tidy, optimised bits of code. They’re messy. They’re running 20 plugins, half of which haven’t been updated in 2 years. They’ve got a theme that’s doing four times more work than it should. They’ve got marketing add-ons firing off database queries like confetti at a wedding.
So if a hosting stack is already 3–5× slower on a clean, simple benchmark, what happens when you throw all that mess at it? Those inefficiencies multiply. A tiny half-second gap becomes a 2–3 second delay. And suddenly your client is asking why their checkout feels like it’s running through treacle. And as traffic grows, things only get worse.
That’s why benchmarks matter. They aren’t the full story, but they’re the truest apples-to-apples comparison we’ve got. Same test, same workload, two different environments — and the difference tells you exactly how much headroom you have before things grind to a halt.
Benchmark Results: “Unlimited” Isn’t Unlimited
So, let’s talk about benchmarks.We tested our own platform against another well-known “unlimited everything” host. You know the type: unlimited disk, unlimited bandwidth, unlimited dreams. The only thing that isn’t unlimited? Reality.
Rather than just trusting the marketing copy, we rolled up our sleeves, got a test account, and ran the exact same benchmark side by side. Same script, same workload, no excuses. Here’s what we found:
- On the “unlimited” host, PHP execution clocked in at about 0.311 seconds. On ours? 0.105 seconds. That’s almost 3× faster.
- For MySQL, things got even more dramatic: 0.904 seconds on theirs, 0.162 seconds on ours. That’s more than 5× faster.
- Add it all up, and their combined PHP+MySQL result was 1.215 seconds compared to just 0.266 seconds on our platform. Nearly 4× faster overall.
But here’s the thing: these numbers came from the cleanest possible test. Just a barebones PHP script and a single MySQL query. No plugins. No bloated themes. No WooCommerce checkout funnel with 27 active extensions.
And both servers were live, not cherry-picked demos. Our test server had over 1,000 sites running on it at the time — real customer workloads, not an empty box humming in a corner. We can’t see exactly how many sites were on the “unlimited” host’s server, but we do know it had hundreds of gigabytes of data already stored. So this was apples-to-apples: both were production machines doing real work.
Even then, the “unlimited” host dragged its feet.
What happens when you throw real-world WordPress into the mix? Those half-seconds balloon into full seconds. That “slight lag” becomes the difference between a cart being abandoned or a sale going through. In e-commerce, every second counts — literally.
So benchmarks aren’t just geeky numbers for nerds like me to get excited about. They’re the canary in the coal mine. And in this case, the canary on the “unlimited” host keeled over about four times faster than ours.
Under the Hood: Why “Unlimited” Feels… Limited
Benchmarks tell us what happened. But the really interesting part is digging into why.When we peeked under the bonnet of the “unlimited” server, the first thing that jumped out was how small the slice of hardware actually is. The underlying CPU is an AMD EPYC 7402P — on paper, a big 24-core processor. Sounds chunky, right? Except here’s the catch: the reseller server only had access to 6 threads total. Not 24. Not 48. Just 6.
CPU: Not All Cores Are Created Equal
And those 6 threads aren’t exactly sprinters. They run at about 3.4GHz, and because this is a virtualised VPS environment, they’re also sharing the physical CPU with other tenants. So even if you’re allocated 6, there’s still a chance you’re elbowing for space with noisy neighbours running who-knows-what on the same node.Compare that with our servers: AMD Ryzen 9 7950X processors. Zen4 architecture. 16 cores, 32 threads, exposed directly to the operating system with no hypervisor middleman skimming performance. And most importantly: those cores boost up to 5.7GHz.
Now, why does that matter? Because PHP (and by extension WordPress and WooCommerce) lives and dies by single-thread performance. Every page request is basically a flurry of PHP instructions that need to be executed fast. The quicker one core can tear through those instructions, the quicker the page loads.
That’s why our benchmark finished in a fraction of the time. It’s not magic, it’s physics: a 5.7GHz Ryzen 9 core just does more work, faster, than a 3.4GHz EPYC slice.
And here’s another kicker. The “unlimited” plan advertises 2 vCPU cores per account. On the surface, that sounds generous. But remember — there are only 6 threads in total for the whole server. If three accounts start getting busy at once, boom — the entire server is maxed out. And that’s before you even count the CPU needed for MySQL or the operating system itself.
So while “2 cores per account” looks shiny in marketing copy, the maths doesn’t hold up. Not all cores are created equal, and when you only have six of them to go around, it doesn’t take much traffic for things to wobble.
On our side, one core does far more heavy lifting, and we’ve got 32 threads to spread that work across. Which means even if multiple accounts get hit with traffic at the same time, the server doesn’t blink.
Memory: Where Speed & Stability Lives or Dies
The “unlimited” host’s server had 32GB of RAM in total, backed by an extra 8GB of swap. Swap is like the emergency brake - it stops things from crashing when memory runs out, but it does it by offloading to disk, which is thousands of times slower. At the time of testing, around 4GB of that swap was already in use, which is like seeing the car running on its spare tyre: technically fine for a bit, but not where you want to be for performance or reliability.MySQL also gets short-changed here. Their configuration only dedicates 2GB to the InnoDB buffer pool — the memory that keeps your database tables and indexes “hot” so queries can be answered instantly. With only 2GB, it’s constantly throwing data out to make space for the next request, which means a lot of queries end up waiting on disk. That’s one of the big reasons our MySQL tests came out five times faster.
By comparison, our servers ship with 128GB of RAM and zero swap reliance. We carve out around 50GB purely for the InnoDB buffer pool, which means most customer databases live comfortably in memory. That’s why queries on our side don’t just start faster — they stay fast, even under load.
And while their reseller plan advertises “4GB RAM per account,” the maths doesn’t quite add up. With only ~32GB total, it wouldn’t take many busy accounts to ask for more memory than the server physically has. When that happens, CloudLinux steps in like a strict referee: processes get slowed or killed, and because swap is already in play, the whole node risks grinding down. On paper, 4GB per account sounds generous. In reality, it’s more like offering everyone an unlimited buffet in a room with just a dozen plates. It’s a disaster waiting to happen.
Disk & Storage: Storage That Isn’t as Endless as It Seems
Here’s the funny thing about “unlimited” disk space: it doesn’t mean the server actually has unlimited storage bolted onto it. Under the hood, it still comes down to real, finite volumes — and those volumes have limits.On this “unlimited” host’s server, the main customer data drive is 600GB. At the time of testing, over 500GB of that was already used, leaving just ~90GB free. Their MySQL database volume is 50GB, with ~39GB free. So while the marketing says “unlimited,” the maths says “already pretty full.” And when the margin is this small, it doesn’t take much to run out of room. A few big media uploads, or a runaway log file spiralling out of control, and suddenly you’re at the ceiling. We’ve seen logs grow by tens of gigabytes in just minutes — so that kind of headroom disappears faster than most people realise.
Yes, they can technically expand those volumes, but that usually means resizing partitions, which often requires downtime risk, and of course there’s a cost attached. “Unlimited” is really just “limited, until you hit the fair use policy.”
The “eat-all-you-can” buffet analogy works for food because people have a finite appetite. Hosting doesn’t work like that. People will fill whatever space they’re given, whether they need it or not. A 50GB error log? Sure — why bother fixing the error. An email inbox hoarding 200GB of messages? Fine — until it slows down backups or causes problems for every other email user on the same server. It might sound harmless on paper, but when it’s another reseller’s client chewing through space and dragging down performance, it stops being a perk and starts being a headache.
By contrast, we don’t pretend storage is bottomless. We charge for disk space and set a clear cap, because it’s a sustainable, transparent model where you pay for what you use. That encourages healthier hosting habits and makes it easier to build your own plans around real value: high-performance NVMe storage, plenty of headroom, and speed that your clients can feel.
In testing, our disks wrote at 692 MB/s (about 55% faster) and read at 4.0 GB/s (more than three times quicker). Since most workloads are read-heavy (databases, CMS requests, page loads), that performance isn’t theoretical, it’s why sites feel consistently faster and more stable here. And because we maintain terabytes of spare capacity, there’s no scrambling to resize volumes or invoke fair use when clients grow.
So while “unlimited” looks good in a sales pitch, in practice it’s a gimmick. Hosts don’t have infinite disks — there are always real costs and real limits. The hidden caveat is the fair use policy, which gives them an escape hatch when customers push things too far. And when you combine that with disks already running hot, it’s a recipe for problems: a sudden surge in uploads, a runaway log file, or one bloated mailbox can tip the server into crisis
Our model is upfront, sustainable, and designed for long-term performance; exactly the kind of foundation you want if your clients’ businesses depend on their sites.
Web Server: Why the Engine Behind the Scenes Matters
The “unlimited” host’s setup is running Apache behind the scenes, with Nginx bolted on in front as a reverse proxy. That’s a pretty common pattern because both Apache and Nginx are free and widely supported, and come as standard with cPanel. But the reality is that Apache is yesterday’s technology. It was designed in the mid-90s, when websites were mostly static HTML and traffic looked like “a few people clicking around.”Fast forward to today, and web servers aren’t just handling human visitors. They’re dealing with armies of bots — search engine crawlers, uptime monitors, SEO tools, scrapers, brute-force attacks, vulnerability scanners. On some sites, automated traffic outnumbers human traffic ten to one.
Apache just wasn’t designed for this world. Every single request, whether it’s a customer adding to cart or a bot hammering login pages, spins up a new process and eats CPU and memory. Under heavy load, it doesn’t take much before Apache is burning cycles just to keep up, leaving less power for the traffic that actually matters. It’s a big reason why sites on Apache stacks can feel sluggish or fall over during spikes.
LiteSpeed, which we use, was built for this modern reality. It’s event-driven, lightweight, and tuned for dynamic apps like WordPress and WooCommerce. It can handle thousands of simultaneous requests without gobbling resources, so even when bots are hammering away, legitimate visitors see smooth performance.
And because LiteSpeed uses far less CPU and memory per request, it frees up more headroom for PHP, MySQL and email to keep humming along. That efficiency is why independent benchmarks consistently show LiteSpeed outpacing Apache/Nginx — not just in synthetic tests, but in real-world conditions where noise traffic is part of daily life.
So why don’t all hosts use it? The answer’s simple: cost. Apache and Nginx are free. LiteSpeed is commercial and licensed. Picking the free option protects the host’s margins; picking LiteSpeed delivers faster, more reliable sites. At Kualo, we think that difference is worth the investment.
Caching: Not Just Faster, Smarter
The “unlimited” host does make use of Nginx caching, which, to be fair, is better than nothing. It can help speed up static assets like images, CSS and JavaScript, and in cPanel it’s even been made a toggleable feature. But when it comes to dynamic content — the real heart of most modern websites — Nginx caching quickly runs out of road. Logged-in users, shopping carts, personalised dashboards, search results… all of these often bypass the cache entirely, or risk showing stale data if caching is forced.LiteSpeed takes a completely different approach. Its server-level cache isn’t bolted on afterwards — it’s baked right into the web server itself. That means it can accelerate dynamic content safely, intelligently, and without hacks. It understands the difference between public and private cache, it knows how to “punch holes” for personalised bits of a page while still caching the rest, and it integrates with a wide range of applications beyond just WordPress — think Joomla, Magento, Prestashop, XenForo and more.
The result is that instead of just serving static assets a bit quicker, entire dynamic pages can be served instantly from cache, even when users are logged in. That’s why LSCache isn’t just faster, it’s more usable in the scenarios that matter most for your clients.
And caching doesn’t stop there. Under the hood, our stack also supports object caching — which means speeding up not just full pages, but the database queries and API calls behind them. Even though some hosts do offer Redis, we go further: our stack runs on KeyDB, a high-performance drop-in replacement for Redis that offers extra features and better throughput. It’s part of the same design philosophy we apply everywhere: pick the best-in-class tech, not just the easiest or cheapest to deploy.
Caching is often invisible, but it’s the difference between a site that feels “instant” and one that feels like it’s dragging its heels. When paired with LiteSpeed’s efficient web server, our caching stack ensures even complex, database-heavy applications keep their speed under pressure.
Security: Strong on the Surface, Gaps Beneath
On the surface, the “unlimited” host’s security setup looks reassuring: CloudLinux and Imunify360 are both present. CloudLinux brings account isolation and stability, Imunify360 adds a web application firewall and malware detection. On paper, that’s a strong baseline, we use these tools, we know they’re solid.We already know that the maths doesn’t add up with their resouce allocations - they’re far too high than what the underlying server can safely support, so CloudLinux’ stability feature is non-existent. But when we scratched beneath the surface, we found more gaps.
Despite running CloudLinux, they’re not actually using CloudLinux’s hardened PHP builds. Instead, they’re using cPanel’s default PHP. That’s fine if every site runs on the latest supported PHP versions, but in reality, resellers often have clients who need PHP 7.4 or older because of legacy themes or plugins.
The problem? Those older versions are end-of-life and no longer receive security fixes in their setup. So if a client insists on an older PHP, it’s essentially left unpatched. On our platform, hardened PHP means even older versions continue to receive backported security updates, closing that gap.
Then there’s what we add on top: Patchman. This runs quietly in the background, scanning WordPress, Magento, Joomla, and Drupal installs, and automatically patching vulnerabilities in core files and even some key plugins like WooCommerce. Across our platform, Patchman patches hundreds of thousands of vulnerable files each year. Those are real security holes being silently fixed before they can be exploited.
For a reseller, this matters enormously. Without hardened PHP or proactive patching, it’s left to you and your clients to update everything the instant a new vulnerability is announced. Miss a patch window, and you risk hacked sites, clean-up jobs, angry clients, and the reputational damage that follows. With our multi-layered approach those risks are dramatically reduced.
So while the surface looks good, the deeper story is that critical layers are missing. And for resellers, that gap can mean the difference between a stable, secure client base — or spending your weekends firefighting malware infections.
The Big Picture: What Clients Really Care About
On paper, what this other reseller host offered looked the same. But scratch beneath the surface and the reality was very different: a small slice of virtualised hardware. Six CPU threads doing all the heavy lifting for dozens (maybe hundreds) of resellers. Thirty-two gigs of RAM, already leaning on swap. A disk volume with just 90GB free, already well-used. Apache grinding away behind Nginx. And no hardened PHP or Patchman quietly keeping the cracks sealed.Our tests made the gap tangible: almost 4× slower overall, 5× slower on database queries, 3× slower on PHP code. And remember, those were simple benchmarks. Real-world sites with plugins, themes, checkout flows, or brute-force traffic hammering them? That’s when the weaknesses multiply.
This is why we’ve built things differently. Bare-metal servers with some of the fastest CPUs on the planet. Huge amounts of RAM, with databases running in memory instead of spilling onto disk. NVMe storage with both space and speed to spare. LiteSpeed and LSCache at the core, Redis and Memcached under the hood, Patchman quietly fixing hundreds of thousands of vulnerabilities every year. It’s a stack designed not just for today, but for the messy reality of tomorrow — traffic spikes, buggy plugins, overlooked updates, the weird things clients do that you don’t find out about until it’s already on fire.
And that’s the real point. You can save a few quid chasing marketing gimmicks, but the grass isn’t usually greener - it just looks greener until you scratch the surface. What really matters isn’t the headline feature list, it’s how the platform holds up when things get busy, when clients push the limits, when reality hits.
Your clients won’t ever ask about the GHz of their CPU, or how large your InnoDB buffer pools are. But they will ask why their checkout is slow, their site is down, or why their site was hacked. As an agency or reseller, those details should matter to you. Those are the real-world symptoms of what’s missing under the hood, and what make the difference between clients staying loyal or leaving frustrated.
That’s why we’ve had agencies stay with us for more than two decades. Because when their clients stay happy, resellers stay confident. And when the hosting holds up under pressure, everyone wins.
The opportunity is in how you position that: showing prospects that you’re not just selling hosting, but a platform that keeps their business fast, safe, and online when it matters most.
That’s the hidden value we offer, and it’s what will set you apart.
