VPS vs dedicated server: which one does your workload actually need?

The honest answer is that most workloads should start on a VPS and move to dedicated hardware only when a specific resource becomes the bottleneck. The useful question is not "which is better" but "which resource am I about to run out of".

What a VPS actually is

A KVM virtual machine is a real kernel running on virtualised hardware. The hypervisor carves a physical machine into slices and hands each guest its own CPU, memory, disk and network devices. From inside the guest you cannot tell the difference by looking at the OS: lscpu reports vCPUs, free reports RAM, and you have root.

What is shared is the thing underneath:

• CPU time. A vCPU is a thread on a physical core. Even with reserved or pinned allocation, other guests on the same host are competing for the same last-level cache and memory controllers.
• Memory bandwidth. This is the resource people forget. Two workloads on one host each get their own RAM, but they share the bus that feeds the CPUs from it.
• Disk. NVMe volumes are fast, and on a good platform they are provisioned with real IOPS guarantees. They still land on a shared controller and a shared set of drives, so a neighbour running a badly configured database can show up in your iowait.
• Network. The port is shared. Burst is usually fine; sustained multi-gigabit throughput is not something to assume.

What dedicated hardware actually buys you

A dedicated server is the whole machine: every core, every memory channel, every PCIe lane, the RAID controller, and a port that nobody else is using. There is no hypervisor between you and the hardware unless you install one.

The practical consequences:

• Predictable tail latency. No steal time, no cache contention, no unexplained p99 spikes at 3pm.
• Memory-bandwidth-bound workloads run properly. Large in-memory databases, big JVM heaps and analytics jobs are frequently bandwidth-limited, not core-limited.
• Real disk topology. You choose the drives, the RAID level and the cache policy instead of accepting a virtual disk.
• Hardware passthrough. GPUs, HBAs and specialised NICs are either straightforward or impossible depending on the platform; on bare metal they are yours.

Read your own metrics before deciding

You do not need a benchmark suite. Three numbers will usually settle it.

1. CPU steal time

On Linux, top shows a st column and vmstat 1 shows st as well. Steal time is the percentage of time your vCPU wanted to run but the hypervisor scheduled something else.

vmstat 1 10
# procs -----------memory---------- ---swap-- -----io---- --system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  2  0      0 891244  12044 402118    0    0     4    18  812 1204  9  3 87  1  0

Sustained st above a few percent during your peak hours means the host is oversubscribed for your workload. Occasional blips are normal. A flat line at 0 with us near 100 means the machine is simply too small and a bigger instance fixes it.

2. Disk latency under load

iostat -x 1 gives you await (average time per I/O, in milliseconds) and %util per device. A healthy NVMe volume sits in the low single-digit milliseconds under a normal database load. Double-digit await with high %util means you are queueing, either because the volume is too small or because the host is busy.

3. Memory headroom and page cache

If free -m shows your page cache permanently starved and si/so (swap in/out) are non-zero, the workload wants more RAM than the instance has. That is a sizing problem, not a platform problem, and it will not be fixed by moving to bare metal.

The decision, in plain terms

Choose a VPS when:

• Your app is stateless or nearly so, and the database is small enough to fit comfortably in RAM with room for the page cache.
• Load is spiky. Paying for a whole machine to handle a Tuesday lunchtime spike is waste, and resizing a VM is a reboot rather than a purchase order.
• You need several environments. Three staging boxes cost less than one dedicated server.
• You are still measuring. Optimise the application before buying hardware.

Choose dedicated when:

• Steal time or memory bandwidth is the limit, not core count.
• You need more RAM than a sensible VM shape offers, or a specific CPU generation.
• You are consolidating many small services onto one box and the per-core economics flip.
• Compliance or isolation requirements say single-tenant, full stop.
• You need GPUs, specialised NICs or large local disk arrays.

A note on "dedicated vCPU"

The phrase means different things on different platforms. At its weakest it means "we promise not to oversubscribe this tier". At its strongest it means the vCPU is pinned to a physical core and cannot be scheduled elsewhere. Ask which one you are buying, because the difference is exactly the steal time you will or will not see.

Migrating later is fine

Nothing about starting on a VPS is a trap. Keep your provisioning reproducible, keep state in a database or object store rather than on the root disk, and moving to bare metal becomes a restore plus a DNS change rather than a re-architecture.