VDS vs VPS: Steal Time, Memory Bandwidth and Cost per Usable Core

VPS and VDS plans are frequently listed side by side at nearly the same price with nearly the same headline specs, which makes the decision look cosmetic. It is not. The difference sits one layer below the control panel: in how the provider commits physical resources to your slice, and in what happens when a neighbour’s workload spikes. This comparison puts numbers on that gap — steal time, memory bandwidth, disk latency, and cost per usable core across three years.

Definition first: the only difference that matters

A VPS is a slice of a shared node with a virtual CPU allocation that the provider may oversubscribe, typically between 2:1 and 8:1. A VDS (virtual dedicated server, sometimes sold as “dedicated resources” or “private vCPU”) is still virtualized, but the provider commits CPU cores and RAM without oversubscription — your vCPU maps to a guaranteed slice of a physical core, and the host reserves the memory pages it sells.

Steal time: the metric that predicts real capacity

Steal time is the percentage of time your vCPU was runnable but the hypervisor scheduled another tenant’s work instead. On a healthy VDS it sits under 1%. On oversubscribed VPS nodes it is workload-dependent: a quiet node may show 0.3%, and the same plan on a busy node shows 12–20% during evening peaks. The practical conversion is direct — a host with 15% average steal delivers about 85% of the CPU you were sold, which turns an advertised “4 vCPU” into roughly 3.4 cores of usable throughput.

Measure it with vmstat 2 60 and read the st column, or top and read %st. Run the test at 20:00 local time in the provider’s region, not at 04:00 when you first provision the box. If steal time exceeds 5% for more than ten minutes a day, the plan is not sized for latency-sensitive work.

Memory bandwidth: the hidden oversubscription

Even without CPU oversubscription, memory bandwidth is a shared resource. A node with 8 DDR5-4800 channels serves roughly 300 GB/s across all tenants. On an oversubscribed host running 6:1 CPU overcommit, aggregates can saturate those channels, and each tenant sees latency-bound behaviour even at low CPU utilisation. Measure with a simple STREAM-like loop or sysbench memory run at several times of day. A VDS on the same silicon typically holds within 5% of its baseline; a VPS can swing 30–40%.

Disk latency: the cheapest differentiator to test

Random 4K read latency at queue depth 1 is the best single-number proxy for VDS quality. Enterprise NVMe on a committed-resource host lands at 80–150 µs. Shared VPS storage with a throttled pool often sits at 400–1,200 µs at peak. The gap matters for databases and world saves, where a 1 ms floor becomes a 40 ms stall under write bursts.

• fio --name=randread --rw=randread --bs=4k --iodepth=1 --runtime=60 --numjobs=4 — check clat p99, not just IOPS.
• ioping -c 100 . — quick latency distribution without a full fio install.
• Repeat at three times of day; a stable p99 is worth more than a fast p50.

Cost math: when the premium pays for itself

Model a three-year run for a workload that needs 8 usable cores and 32 GB.

The VDS premium is 45% over the VPS but only 14% below bare metal. That narrow band is why the decision often becomes VPS-or-bare-metal: if you need deterministic performance, going the last step to dedicated hardware removes the hypervisor entirely and usually adds full IPMI access. The VDS sweet spot is workloads that need isolation but cannot justify a full machine — a single database replica, a staging environment, or a small game instance that must not share a scheduler with noisy neighbours.

Workloads that justify the VDS premium

• Transactional databases. Steal time on the commit path multiplies lock waits; 8% steal can double p99 query latency.
• Game servers with a fixed tick. A missed tick budget is visible to players as rubber-banding, regardless of average CPU load.
• Build and CI runners. Compile times become unpredictable when cores are shared, which stalls pipelines and wastes developer hours.
• Anything with an SLA attached. Performance variance is the enemy of a published latency promise.

When the cheaper VPS is the correct answer

If the workload is burst-tolerant — batch processing, a low-traffic site, a development box, a backup target — oversubscription is a rational discount. You are buying statistical capacity and paying less for it. The mistake is buying it for a latency-bound workload and discovering the oversubscription ratio only after launch. Ask the provider for the oversubscription ratio in writing; a provider that cannot state it is either unaware or unwilling to disclose it.

A four-step verification sequence

First, provision and immediately run lscpu plus a 10-minute all-core load to record baseline clock. Second, at peak hour, run vmstat for ten minutes and record the steal-time p95. Third, run fio random 4K at QD1 and record p99 latency. Fourth, repeat all three tests at three different times of day and compare variance. A VDS should show under 2% variance in steal and under 15% in p99 disk latency. If it does not, the “committed” label is marketing. When the numbers do hold, and the premium is under 50%, the upgrade is justified — and if your sizing has grown beyond a single node, dedicated server hosting removes the hypervisor layer altogether.

Decision in 60 seconds

Latency-sensitive and staying under one machine: buy VDS and verify steal time at peak. Burst-tolerant and price-sensitive: buy VPS and accept the variance. Growing past eight cores or needing ECC, IPMI, and full NVMe control: skip both and go bare metal, where the cost-per-core gap narrows to a few dollars a month.

Related Articles：

Modpack Memory Ceilings: Why 16 GB Stops Working at 180 Mods Backup and Restore Windows on Game Servers: RPO, Save Freezes and Storage Maths DayZ Dedicated Server Hardware: CPU, RAM, and Storage Requirements for 60 Players Pterodactyl vs Pelican at Scale: Running Game Server Panels on Dedicated Hardware