VPS vs VDS: What Actually Changes (2026 Guide)

A VPS and a VDS are both virtual machines on a physical host. The difference shows up when the host gets busy. A VPS gives you a guaranteed slice of shared hardware, so the hypervisor schedules your CPU time alongside every other tenant on that node. A VDS, by contrast, gives you dedicated, isolated resources, so your cores stay yours whether the node is quiet or hammered. That single difference drives the whole product: you buy a VPS for value, and you buy a VDS for predictability.

So everything below explains how to tell which one you actually need, and how to prove it on the server you are running right now.

The thing nobody names: your slice is scheduled, not owned

Here is what happens underneath a standard VPS. A hypervisor sits on the physical machine and hands out CPU time to every virtual machine on it. Your VPS has, say, 4 vCPUs. Those vCPUs are not four pieces of silicon reserved for you. Instead, they are four queue positions. When your workload wants to run, the hypervisor decides whether it gets the physical core now or in a moment.

Most of the time, that moment stays invisible. Hosts run on the assumption that tenants will not all peak at once, which is exactly why a VPS costs a fraction of dedicated hardware. The trade is real, and the trade is fair.

When the neighbour gets loud

But the moment stops being invisible when another tenant on your node starts a build, runs an analytics job, or catches a traffic spike. Suddenly your requests wait. Linux has named that waiting for over fifteen years. IBM’s Linux performance documentation put it plainly: steal time is the percentage of time a virtual CPU waits for a real CPU while the hypervisor is not scheduling it (IBM, CPU time accounting). The top man page is blunter still, calling the st field time stolen from this VM by the hypervisor (top(1)).

The industry term for the neighbour causing it is exactly what you would guess: the noisy neighbour. Red Hat’s virtualization guidance draws the straight line between the two. It notes that large amounts of steal time indicate CPU contention which can reduce guest performance, and that the fixes all sit host-side: raise the guest’s priority or quota, or run fewer guests on the host (Red Hat, Steal Time Accounting).

Read that last part again. Every fix lives on the host side. You cannot tune your way out of steal time from inside your own server. That is what sets it apart from every other performance problem you own.

VDS: same virtualization, different allocation

A VDS, short for Virtual Dedicated Server, is still a virtual machine. It still runs on a hypervisor. The allocation model is what changes. Instead of handing you a scheduled slice of a shared pool, a VDS reserves dedicated resources for you on the physical host. Nobody else takes the cores backing your VDS while you wait.

You can read the intent in how the plans name their CPU. Rabisu’s VPS plans count in vCPU: “2v Ryzen CPU”, “4v Ryzen CPU”. The VDS plans count differently, in cores: “2 Core CPU”, “4 Core CPU”, “6 Core CPU”. Kaya VDS X4 gives you 2 cores, 4 GB RAM, and 40 GB NVMe. Kaya VDS X32 gives you 6 cores, 32 GB RAM, and 180 GB NVMe. Same hardware family, AMD EPYC and Ryzen or Intel Xeon, same NVMe storage, same 13 plus locations. Different allocation.

So what does the move actually buy you? Not raw speed. A VDS core and a VPS vCPU on the same generation of silicon do the same work per cycle. Instead, it buys variance reduction. Your p95 stops drifting, build times stop landing in a range, and the incident log stops filling up with “could not reproduce”.

It does not, however, buy you hardware control. Other tenants still share the physical machine at the box level, and you still do not pick the CPU model, the disk layout, or the NIC. For that, you need bare metal.

VPS vs VDS vs dedicated: the comparison table

The honest read on this table: most projects should start on a VPS and stay there. You do not move to a VDS because you want more. Rather, you move because you measured something first.

So here is how to measure it.

The proof hook: run the noisy neighbour test

This test takes 60 seconds and works on any Linux server from any provider, including ours. You are hunting for one number: %steal.

Step 1. Install sysstat

First, install the tools if you do not already have them.

bash

sudo apt install sysstat -y    # Debian / Ubuntu
sudo dnf install sysstat -y    # Rocky / Alma / Fedora

Step 2. Sample every CPU during real traffic

Next, sample all your CPUs once a second for a full minute.

bash

mpstat -P ALL 1 60

The %steal column holds the answer. The man page defines it as the percentage of time spent in involuntary wait by the virtual CPU while the hypervisor was servicing another virtual processor (mpstat(1)). Run it during your busy window, not at 3am, because contention only shows up when there is contention.

Step 3. Read the result

Treat the 10 percent line as a widely used rule of thumb, not a hard standard. The common framing holds that steal time above 10 percent sustained for around 20 minutes means the VM runs slower than it should (Scout Monitoring). So use it as a trigger to investigate, not a law. If you run a trading bot or a database serving user-facing reads, you will care well before 10 percent, because tail latency degrades long before the average does.

Step 4. Correlate before you spend

Finally, do the step most people skip. Line up your %steal samples against your own latency graphs. If steal spikes and p95 spike together, you have your evidence, and isolated cores will fix it. However, if steal stays flat while latency is still bad, isolated cores will fix nothing, and you just found that out for free.

If you prefer other tools, top and iostat -c 1 30 show you the same field. Red Hat’s own engineering write-up on detecting steal time in guests walks through reading it straight from top (Opensource.com). And if %st is missing from top on your kernel, fall back to mpstat.

That is the whole test. It is not our test, it is the platform’s test, and it works the same against every host you have ever paid.

Why Rabisu

Price-to-performance is our whole argument, and that argument only works if you can check it. So we made two things easy to check.

First, our VDS page publishes a live statistics panel: average hypervisor CPU usage, total cores, provisioned memory, provisioned NVMe, and current network throughput. Not a screenshot. Not a number from a launch post. It shows the current state of the fleet, right on the page where we ask you for money. Go look before you order, then look again after.

Second, our Looking Glass lets you test real latency from your location to any of our data centers before you spend a cent. Every location page publishes a test IP for exactly that reason.

If you are running a website, a dev box, or a small community server, start on a VPS. It is cheaper and it is enough. If you have run the test above and watched steal time climb while your users waited, move to a VDS. If you need the whole machine and control of the hardware in it, take a dedicated server.

We would rather you buy the right one twice than the wrong one once.

Quick Answers