An online store on a virtual server answers in 120 ms in the morning, then its response time jumps to a full second at 9 pm, while CPU usage inside the server never passes 40%. In most cases the cause isn’t the code or the database: it’s the physical cores your server shares with other servers on the same machine. That is the real difference between a (VPS) and a (VDS). It isn’t the operating system or root access. It’s one question: are the CPU cycles guaranteed to you or not?
01The difference in two sentences
Both are virtual machines running on a such as KVM, each with its own OS kernel, virtual disk and IP address. On a VPS you get virtual cores (vCPUs) time-sliced on physical cores you share with others; on a VDS you get specific physical cores or threads that nothing else is scheduled on.
The terms aren’t standardised: some providers call any KVM server a VDS, others sell a VPS with dedicated cores. So don’t judge by the name. Read the plan: does it say shared vCPU or dedicated vCPU? Does the provider state its CPU ratio?
02What happens under the hood
CPU
A modern physical server has dozens of cores. In the VPS model the provider sells more virtual cores than there are physical ones, at ratios like 1:4 or higher, betting that servers won’t all max out their CPU at the same moment. While the total load stays moderate, you won’t notice anything. But when the neighbours get busy together, your virtual core waits for its turn, and that wait shows up as .
On a VDS your virtual cores are pinned to specific physical cores (CPU pinning), so they’re never sold to anyone else. The result is predictable performance and steadier latency in the high percentiles, p95 and p99, which are the ones users actually feel.
Memory
Under full virtualization such as KVM, memory is usually reserved per server on both types. Some providers use techniques like memory ballooning to reclaim unused RAM, so ask about it if your applications are sensitive to available memory.
Storage and network
Here’s a common misconception: “dedicated” on a VDS usually means CPU and memory, not disk or network. The storage array and the network card stay shared in both cases, with per-server caps on read/write operations (IOPS) and throughput. If your problem is a slow disk, moving to a VDS alone won’t fix it.
03Side by side
| Criterion | VPS | VDS |
|---|---|---|
| CPU | Shared, overcommitted vCPUs | Cores or threads reserved for you |
| Performance stability | Usually good; fluctuates when neighbours peak | Steady and predictable |
| Steal time | Can rise at peak hours | Close to zero |
| Memory | Reserved under full virtualization | Reserved |
| Storage and network | Shared, capped per server | Usually shared, sometimes with higher caps |
| Isolation | Own OS kernel per server | Own kernel, plus cores no one else uses |
| Cost | Lower | Higher, because the provider can’t sell a core twice |
| Upgrades | Usually quick, with a reboot | Needs free cores on the host; may require migration |
04Isolation and security: where the difference really is
It’s often said that a VDS is “more secure” than a VPS. More precisely, the basic isolation is the same: under full virtualization each server has its own kernel and reserved memory, and can’t see its neighbour’s files or processes. The real security difference shows up in two places:
- Virtualization type: Some cheap offers labelled VPS are container-based (OpenVZ or LXC, for example), so every server shares the host’s kernel. That’s far weaker isolation than KVM, and it limits loading kernel modules and running Docker.
- Side channels: When servers share physical cores and their caches, Spectre-class side-channel attacks between neighbours remain theoretically possible. Dedicated cores shrink that surface, which matters for systems that process financial or health data and face compliance audits.
Your server’s day-to-day security depends on your configuration more than on its type: SSH keys instead of passwords, a firewall that closes every port you don’t need, and regular security updates.
05How to measure what you actually get
Don’t rely on the plan’s name. Three measurements in half an hour tell you what’s happening on your server. Install the tools first on Ubuntu or Debian, then start with the CPU:
sudo apt install -y sysstat sysbench fio# CPU model and the cores your system seeslscpu | grep -E "Model name|Thread|Core|Socket"# Steal time per core (%steal column), every second for a minutempstat -P ALL 1 60# CPU performance: run it in the morning, then at peak, and comparesysbench cpu --threads=$(nproc) --time=30 run
# Disk wait times (r_await and w_await columns, in ms)iostat -x 1 10# 4K random reads at queue depth 32 for one minute, then remove the test filefio --name=randread --rw=randread --bs=4k --iodepth=32 --size=1G --runtime=60 --time_based --direct=1 --ioengine=libaio --group_reportingrm -f randread.0.0
Here’s how to read the results:
- Steal time: Under 1% is excellent. If it stays above 5% at peak hours, your server is waiting for its turn on the physical CPU.
- Consistency: A gap of more than 10–15% between the morning and evening sysbench results points to busy neighbours.
- Storage: If %iowait in mpstat rises together with r_await or w_await in iostat, the bottleneck is the disk, not the CPU.
06Which one fits your workload?
| Workload | Best fit | Why |
|---|---|---|
| Company site, blog or small store | VPS | Bursty load; caching serves most requests |
| Development and staging | VPS | Cost matters more than steady performance |
| Mail server, VPN or internal tools | VPS | Low, stable CPU usage |
| Production database with a latency target | VDS | CPU jitter shows up directly in p99 |
| Game and voice servers | VDS | Sudden delays ruin the experience at once |
| CI build servers and batch processing | VDS | Steady run times make planning easier |
| Software licensed per core | VDS | A fixed core count simplifies licensing |
Before you decide, make sure the problem you’re solving really is the CPU. Here are common symptoms and what lies behind them:
- ProblemThe site slows down in the evening although CPU usage inside the server is low
- FixCheck %steal with mpstat at the same time. If it’s high, ask your provider to move you to a less crowded host, or switch to dedicated cores.
- ProblemUpgrading to more cores didn’t improve response time
- FixPHP and Node.js handle each request on a single core. Profile the slow requests and enable caching before buying more cores.
- ProblemThe database is slow on writes
- FixWatch w_await in iostat. If the bottleneck is the disk, the fix is in storage or database tuning, not in the server type.
07Practical recommendation
Start most projects on a VPS, and watch steal time and p95 response time for two weeks under real load. If the numbers stay stable, there’s no reason to pay for dedicated cores. If steal time passes 5% at peak, or database latency starts breaking what you promised your customers, it’s time to move.
If you’re starting on CoreVPS, its servers run full virtualization on AMD EPYC 9454P processors, DDR5 ECC memory and NVMe storage in RAID 10. Run the three measurements on day one and keep the results as a baseline to compare against whenever you doubt performance.
