{"id":84,"date":"2025-11-28T01:44:34","date_gmt":"2025-11-28T01:44:34","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=84"},"modified":"2026-09-12T22:04:46","modified_gmt":"2026-09-12T22:04:46","slug":"the-definitive-guide-to-virtual-dedicated-server-vds-virtual-private-server-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/the-definitive-guide-to-virtual-dedicated-server-vds-virtual-private-server-vps\/","title":{"rendered":"VDS vs VPS by Workload Type: Choosing CPU Isolation for Databases vs Web Servers"},"content":{"rendered":"\n

VDS and VPS instances are usually compared with a single number: CPU steal. But steal only matters in proportion to what your server actually does. A static web server idling at 4% CPU will never notice a noisy neighbor. A PostgreSQL instance pushing 800 transactions per second feels every stolen cycle as rising p99 latency. This guide separates the VDS-versus-VPS decision by workload type<\/strong>, so you buy isolation where it pays and skip it where it does not.<\/p>\n\n\n\n

How the Hypervisor Maps Your vCPUs<\/h2>\n\n\n\n

Both products hand you a virtual machine. The difference is scheduling. On an overcommitted VPS, a 16-core host may sell 32 or 48 vCPUs, betting that tenants do not peak simultaneously. Your vCPU is a time-slice on a physical core that others also use. On a VDS, physical cores are pinned to your instance and the scheduler is never allowed to place another tenant on them.<\/p>\n\n\n\n

That pinning is what eliminates %st<\/code> (steal) from top<\/code>. You can see the current value directly:<\/p>\n\n\n\n

top -bn1 | grep \"Cpu(s)\"\n# look for the st% field\nvmstat 1 5 | awk 'NR==1 || NR>2 {print $1, $15}'   # column 15 = st<\/code><\/pre>\n\n\n\n
Database Workloads: Where Dedicated Cores Pay Off<\/h2>\n\n\n\n
Database engines are latency-shaped, not throughput-shaped. A PostgreSQL or InnoDB backend holds a lock for a fixed number of operations, and that critical section runs on one core. When steal interrupts it, the lock is held longer, other transactions queue behind it, and tail latency inflates faster than average CPU usage suggests. This is why a database can show only 45% CPU utilization yet exhibit 3x worse p99 latency under contention.<\/p>\n\n\n\n
For read-heavy web workloads you can often absorb this. For write-heavy or OLTP databases, the isolation premium is the cheapest latency insurance you can buy. The same logic applies to anything with a serialized critical path: Redis with persistence enabled, game-server tick loops, and message brokers.<\/p>\n\n\n\n
Web and Application Workloads: Where Sharing Is Usually Fine<\/h2>\n\n\n\n
PHP-FPM workers, Node.js request handlers, and static file servers are horizontally parallel. If a vCPU is descheduled for 4 ms, another worker on a different vCPU keeps draining the accept queue. Users see a marginally slower request, not a stalled system. Bursty traffic is absorbed by a worker pool that is provisioned for the peak anyway.<\/p>\n\n\n\n
For these workloads, spending 30% more on a VDS usually buys nothing measurable. You are better off spending that budget on more RAM for page cache or on a CDN in front of the origin. This is exactly the trade-off explored in our write-up on the practical benefits of cloud VPS capacity<\/a> \u2014 burstable shared capacity handles spiky web traffic well.<\/p>\n\n\n\n
Measuring the Difference Yourself<\/h2>\n\n\n\n
Do not trust marketing numbers. Reproduce the comparison on the instance class you are actually considering. A paired test that isolates scheduling jitter from raw core speed:<\/p>\n\n\n\n
# 1. Raw single-core speed\nsysbench cpu --threads=1 --time=30 run\n\n# 2. Scheduling jitter under contention (the isolation test)\nsysbench cpu --threads=$(nproc) --time=60 run\n\n# 3. Tail latency while CPU is pegged\ntaskset -c 0 stress-ng --cpu 1 --timeout 60s &\nfor i in $(seq 1 200); do\n  S=$(date +%s%N); sleep 0.01; E=$(date +%s%N)\n  echo $(( (E-S)\/1000 ))\ndone | sort -n | awk '{a[NR]=$1} END {print \"p99 (us):\", a[int(NR*0.99)]}'<\/code><\/pre>\n\n\n\n
The third test is the decisive one. On a quiet VDS the p99 sleep overshoot stays within tens of microseconds of the 10 ms target. On a contended VPS it routinely spikes into the low milliseconds.<\/p>\n\n\n\n
Workload-to-Instance Decision Matrix<\/h2>\n\n\n\n
Workload<\/th>Latency-sensitive?<\/th>Recommended<\/th>Why<\/th><\/tr><\/thead>
Static \/ CMS web serving<\/td>No<\/td>VPS<\/td>Parallel workers absorb jitter<\/td><\/tr>
Node.js \/ PHP API<\/td>Low<\/td>VPS<\/td>Worker pool masks steal<\/td><\/tr>
PostgreSQL \/ MySQL OLTP<\/td>High<\/td>VDS<\/td>Lock hold time inflates p99<\/td><\/tr>
Redis with AOF\/RDB<\/td>High<\/td>VDS<\/td>Serialized persistence path<\/td><\/tr>
Game server tick loop<\/td>High<\/td>VDS<\/td>Fixed 16.6 ms frame budget<\/td><\/tr>
CI runners \/ batch jobs<\/td>No<\/td>VPS<\/td>Throughput, not latency<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Memory and Disk Isolation by Workload<\/h2>\n\n\n\n
CPU is only one axis. Databases are also the first to suffer from memory overcommit<\/strong> and burst IOPS caps<\/strong>. Many VPS plans oversell RAM using ballooning and KSM, so free -h<\/code> reports 4 GB while the host reclaims pages under pressure. A database that suddenly loses its page cache falls back to disk reads and its throughput collapses \u2014 even though nothing in your own load changed.<\/p>\n\n\n\n
grep -E 'MemTotal|MemAvailable|Committed_AS|CommitLimit' \/proc\/meminfo\ndmesg | grep -i -E 'balloon|oom|kcompactd'<\/code><\/pre>\n\n\n\n
Web tiers are far more forgiving: they are stateless, can be restarted, and lose nothing when the kernel reclaims cache. Database workloads hold state and care deeply. Combine that with disk \u2014 a plan capped at 3,000 IOPS will starve InnoDB or PostgreSQL checkpoints long before its CPU is busy. For a database, always measure random-read IOPS with fio --rw=randread --bs=4k --iodepth=32<\/code> before trusting the storage label.<\/p>\n\n\n\n
A Practical Migration Path<\/h2>\n\n\n\n