Architecture, Measured
Bare metal vs virtualised — when the hypervisor tax matters, and when it's the bargain
Virtualisation charges a small toll on every operation and hands back snapshots, instant resizes and fast recovery. The engineering question is whether your workload notices the toll more than it uses the refund.
The short answer
For most web workloads, virtualised is the right answer and the tax is a rounding error: modern hardware-assisted virtualisation runs CPU-bound work within a few percent of native, and what you gain — provisioning in minutes, resizing without a screwdriver, snapshots before every risky change, migration off failing hardware — is operational capability bare metal simply does not have.
Bare metal earns its keep where the toll concentrates: sustained disk I/O, where even paravirtualised storage adds queueing above the device; high packet rates, where per-packet costs accumulate; memory-bandwidth-hungry databases; and latency floors, where removing the hypervisor removes variance. If your monitoring shows iowait, steal or a restless p99 under load, the metal argument is real. If it doesn't, you would be paying peak-performance money for a convenience downgrade.
By the HostingFast team · Reviewed 25 August 2026
Near-native
CPU throughput under hardware-assisted virtualisation
I/O
Where the toll concentrates under sustained load
Minutes
To provision or resize a virtual machine
1
Tenant on a bare-metal box: you
Strip the marketing and the trade is precise. A hypervisor interposes on privileged operations, routes I/O through virtual devices, and shares physical caches, memory channels and device queues among guests. Each interposition costs a little; under pressure, the little costs queue.
In exchange, your server becomes data: copyable before an upgrade, resizable when traffic doubles, movable when hardware degrades, rebuildable in minutes rather than in a delivery window. Neither side of that trade is sentimental — both are measurable, which is how this page treats them.
Itemising the tax
CPU is the cheap line: hardware virtualisation extensions let guest code run directly on the silicon, with overhead confined to interrupt handling and world switches — low single digits for web-shaped work. Memory management is similarly mature.
I/O is where the metre runs. Disk and network requests traverse virtio queues scheduled by the host, adding latency that is negligible at idle and compounding under sustained pressure. Shared physical realities — CPU cache, memory bandwidth, the NVMe device's own queue — are divided among guests by arithmetic no configuration escapes. The tax is not one number; it is a function of how hard the box and its tenants are working.
When the tax is noise
A cached website, a moderate-traffic application, an API doing ordinary CRUD — these workloads leave the toll booth unbothered. Requests are short, I/O is bursty rather than sustained, and the latency added per operation vanishes inside network jitter.
For that broad class, virtualisation's conveniences dominate the decision: capacity that follows demand, snapshots that make risky changes reversible, recovery measured in minutes. Choosing bare metal here buys peak numbers your monitoring will never distinguish from the virtualised ones — the definition of paying for the wrong thing.
When the tax is signal
Sustained storage pressure: large databases under constant write load, search indexing, analytics — anywhere iowait is a resident rather than a visitor. Bare metal's unmediated NVMe queue holds latency flat where virtual storage stacks begin to stretch.
High packet rates and latency floors: busy API gateways, real-time workloads, anything whose p99 is a promise to someone. And memory-bandwidth-bound databases, which feel cache and channel sharing that no guest metric names directly. The tell is in your existing graphs: chronic iowait, nonzero steal, tails that wander at load. Metal removes the layer those symptoms live in.
A decision procedure, not a doctrine
Measure a fortnight at real load: steal, iowait, p50 against p99, and where the time goes in your slowest traces. Clean numbers end the conversation in virtualisation's favour; dirty ones justify a bare-metal trial with the same workload and the same instruments.
Hybrids are legitimate engineering, not indecision: the database on metal where the I/O and bandwidth live, the web tier virtualised where elasticity pays. Run the same benchmark on both sides of any migration — the histogram, not the invoice, is what should convince you.
Both architectures, one measurement standard
Our virtual tiers run on nodes provisioned so the tax stays theoretical — steal at zero, NVMe underneath, headroom enforced. That covers the workloads virtualisation genuinely serves best, which is most of them.
When your graphs argue for the whole machine, dedicated hardware gives you the unshared queue, the full memory bandwidth and a p99 with your name on it. We will help you read the metrics either way — the wrong upgrade helps neither of us.
- Virtual tiers on honestly provisioned nodes — steal checked at peak
- Dedicated machines with NVMe and every queue unshared
- The same monitoring standard on both, so comparisons mean something
- Migration between architectures planned, executed and re-measured
Why HostingFast
Standard on every plan
Elasticity where it pays
Resize, snapshot and rebuild in minutes on the virtual tiers — operational speed that bare metal cannot offer at any price.
Peak physics where it counts
Unshared NVMe queues and full memory bandwidth on dedicated hardware, for the workloads that measure the difference.
Advice from the graphs
We recommend the tier your steal, iowait and p99 justify — and put it in writing, so the decision survives the sales call.
Quick Start
From order to online
- 1
Profile a real fortnight
Steal, iowait and p50/p99 at genuine load. The architecture question is answered in those four lines or not at all.
- 2
Locate the time in your slow traces
Waiting on disk under sustained load points at metal; waiting on your own queries points at indexes; waiting on the network points elsewhere entirely.
- 3
Trial, benchmark, and only then commit
Same workload, same instruments, both architectures. Keep whichever histogram is tighter — and keep the elasticity if they tie.
Built In
Loaded onto every plan
- The workload profiled before the architecture is debated — symptoms first, doctrine never
- CPU steal and iowait charted at peak hours across at least two weeks
- NVMe on both candidates, so the comparison isolates the hypervisor rather than the disk
- Operational needs priced in: snapshots, resize speed and recovery time are performance too
- Hybrid split considered — database on metal, web tier elastic — before an all-or-nothing move
- Identical benchmarks run on both sides, with p99 as the deciding line
Frequently Asked
What people ask us most often
What exactly is the hypervisor tax?
The aggregate cost of running under a virtualisation layer: interposed privileged operations, I/O routed through virtual devices and host-side queues, and physical resources — CPU cache, memory bandwidth, device queues — shared among guests. For CPU-bound work it is low single digits; under sustained I/O and busy neighbours it grows into something your latency tail can see.
Is bare metal always faster?
At the limit, yes — nothing is subtracted before your workload runs. In practice, a well-provisioned virtual machine on an honest node is indistinguishable for most web workloads, and the metal's advantage only materialises under sustained I/O, high packet rates or memory-bandwidth pressure. 'Faster in the histogram you actually have' is the standard that matters.
What do I give up by choosing bare metal?
Operational agility: snapshots before risky changes, resizing in minutes, migration off failing hardware, rebuilds without a hardware cycle. Recovery and capacity changes move from software timescales to logistics timescales. If your workload doesn't measurably need the metal, that agility is usually worth more than the unmeasurable speed.
Which architecture suits a busy WooCommerce store?
Start virtualised with the cache and object cache done properly — most stores never generate the sustained I/O that justifies metal. The escalation signal is the database: chronic iowait during trading peaks, buffer pool wanting more bandwidth than neighbours allow. At that point a hybrid — database on dedicated hardware, web tier elastic — usually beats moving everything.
How do I run a fair comparison between the two?
Same workload, same dataset, same instruments, both platforms — ideally replaying production traffic. Compare p95 and p99 under load rather than averages or synthetic peaks, include a sustained-write phase if you have one, and run long enough for caches to warm. An hour of honest replay beats any spec-sheet arithmetic.
Keep reading
Dedicated servers
The unshared machine: full queues, full bandwidth, a p99 of your own.
VPS hosting
The virtualised tier this page defends for most workloads — honestly provisioned.
VPS vs dedicated performance
The same trade measured from the product side, metric by metric.
Hosting glossary
Hypervisor, steal, iowait, NUMA — the terms in this argument, defined.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Let the histogram choose your architecture
Virtual tiers kept honest, dedicated metal when your metrics ask for it, and the same measurement standard on both — migration planned and re-benchmarked.
View Dedicated servers plans