Dedicated Servers vs Cloud VMs: When Bare Metal Wins

Not Which Is Better, But What You Are Paying For

Bare metal versus virtual machines is often argued as though one were modern and the other obsolete. That framing hides the actual trade, which is narrow and easy to state.

A cloud VM sells you elasticity and a control plane. You get a machine in a minute, you destroy it in a second, you pay by the hour, and around it sits an ecosystem of snapshots, load balancers, managed databases and APIs. A dedicated server sells you the whole physical machine: every core, all the memory bandwidth, the full disk queue, and no neighbour.

You are paying for flexibility in one case and for undivided hardware in the other. Whichever you buy, the other one is what you gave up.

So the useful question is not which wins in general. It is whether your workload spends more of its life needing capacity to change, or needing capacity to be consistent.

What You Are Actually Sharing on a VM

A virtual machine is scheduled onto a physical host alongside other tenants. Modern hypervisors are very good, and the raw overhead of virtualization itself is small. The variability comes from sharing, and it shows up in four places.

CPU time. On shared or burstable instance types, your vCPU is a slice of a physical core that other tenants also use. Linux reports the time you were ready to run but were not scheduled as steal time, visible in the st column of vmstat 1. Persistent nonzero steal is the clearest evidence of contention there is.

Memory bandwidth and cache. This is the invisible one. Neighbours competing for last level cache and memory channels slow you down without appearing in any metric your provider exposes.

Storage. Network attached volumes have a provisioned ceiling, and local disks on a shared host are shared too. The distinction between local and network storage matters enough that the NVMe storage article treats it separately.

Network. Packet throughput on smaller instances is usually capped well below line rate, which is felt by proxies and packet-heavy services long before bandwidth-heavy ones notice.

Dedicated CPU instance types exist precisely to remove the first item. They pin you to physical cores and eliminate steal, at a higher rate than shared types. That is often the correct middle step before considering bare metal at all.

The Comparison That Matters

Notice that the row that usually decides it is failure recovery. A VM estate treats machines as replaceable; a bare metal estate has to plan for a machine being gone for a working day. If your architecture cannot absorb that, you need at least two of everything, and the arithmetic changes.

Workloads Where Bare Metal Genuinely Wins

Five patterns come up repeatedly, and they have something in common: steady demand plus a resource that virtualization taxes.

• Large databases with predictable load. A single engine that wants many cores, a lot of memory and low storage latency benefits from all three being undivided. The tuning that follows is covered in running PostgreSQL on a cloud server.
• Sustained batch and build workloads. CI runners, video encoding and scientific jobs run near full utilization for hours, which is exactly the shape that burstable instances handle worst.
• Nested virtualization and container hosts with many small tenants. Running your own hypervisor or a dense Kubernetes node pool is far simpler when you own the machine underneath.
• Storage-heavy services. Log stores, object storage clusters and media libraries want many large disks attached directly, which cloud instance families rarely offer at a sensible ratio.
• Software licensed per physical core. Some enterprise licences count sockets or physical cores, and a dedicated machine makes the count knowable.

The common thread in the other direction is variability. Anything spiky, seasonal, or still finding its shape belongs on instances you can throw away, which is also the argument in the autoscaling explainer.

The Costs Bare Metal Adds Back

The headline attraction is resource per unit of spend, and on that axis dedicated hardware usually wins for steady workloads. Several costs then reappear elsewhere.

You now own capacity planning. A VM that is too small is resized in a reboot; a dedicated server that is too small is a migration. Buying ahead of demand means paying for idle hardware, and buying behind it means an outage.

You own the recovery plan. There is no equivalent of stopping an instance and starting it on healthy hardware, so redundancy must be designed rather than assumed, and your backup copies have to live somewhere else entirely, as the backup strategies guide argues.

You own more of the stack. RAID configuration, firmware, disk health monitoring and occasionally a remote console session at an awkward hour. Providers vary a great deal in how much of this they absorb, which is worth checking before committing.

And you lose the managed services. Nothing on a dedicated server gives you a managed database, a load balancer or a queue, so either you run them yourself or you keep a cloud account alongside for exactly those pieces.

Where the Two Models Meet

The clean split has been eroding for years, and the interesting options now sit between the poles.

European hosts made dedicated hardware approachable first. Hetzner sells both cloud servers and dedicated machines from one account, including an auction of existing hardware, and documents the whole platform in its dedicated server documentation. OVHcloud runs several dedicated ranges alongside its public cloud, and its documentation portal covers how the two connect over a private network. A Hetzner account or an OVHcloud account therefore gives you both models behind one control panel, and the Hetzner and OVHcloud comparison covers how their portfolios differ.

From the other direction, the hyperscalers sell metal too. AWS offers bare metal instance sizes in most modern families, exposing the full physical machine while keeping VPC networking, security groups and snapshots. That combination removes the usual objection about losing the ecosystem, at a rate that reflects the whole host.

The practical middle ground for most teams is a hybrid: dedicated machines for the steady, resource-hungry core, cloud instances for everything that changes. Keeping both under one provider makes the private link between them trivial, as covered in private networking between cloud servers.

Key Takeaways

• The trade is elasticity against undivided hardware. Decide which your workload needs more of the time.
• Check steal time before blaming the hypervisor. A dedicated CPU instance type may solve the problem without leaving virtual machines.
• Bare metal wins for steady, resource-hungry workloads: large databases, sustained batch, dense container hosts, storage-heavy services and per-core licensing.
• Recovery is the hardest thing you take back. Plan for a machine being unavailable for hours, not minutes.
• Capacity planning, firmware and disk health become your job, and no managed services come with the box.
• Hybrid is normal. Run the predictable core on metal and keep elastic capacity next to it on the same private network.