VPS, VDS or dedicated server: what the words mean

Three words, sold at three prices, and only one of them has a definition everyone agrees on. A dedicated server is a physical machine that nobody else is on. A VPS is a virtual machine on a shared physical machine. A VDS is a VPS whose seller wants you to know that the CPU share is not oversubscribed - which is sometimes a real technical difference and sometimes a rebranding. The useful question is never "which of the three do I want", it is "what exactly is guaranteed, and can I check it once the box is running". This post answers both, including the commands that tell you what you actually bought.

The three words, and which one is marketing#

VPS stands for virtual private server. It means a virtual machine: a slice of a physical host, with its own operating system, its own IP address, and root access inside it. The word says nothing about how the slice is cut. A 1 GB VPS from one provider and a 1 GB VPS from another can differ by a factor of three in real performance, and both descriptions are accurate.

VDS stands for virtual dedicated server. The industry uses it to mean a VPS where the resources are not shared: your vCPU are pinned or reserved rather than fought over, your memory is not overcommitted, and your disk allocation is real. There is no standards body enforcing that, which is the whole problem. Some providers use VDS precisely; others use it as a synonym for VPS with a higher price. The word is a claim, not a specification, and a claim is worth exactly as much as what sits next to it: a named CPU model, a stated vCPU count, and an answer to "do you overcommit".

Dedicated server means the entire physical machine. One tenant, one set of hardware, no hypervisor between you and the CPU unless you install one yourself. This is the only one of the three with an unambiguous meaning, and the price reflects it.

The honest hierarchy is not VPS then VDS then dedicated. It is: how much of a physical machine is guaranteed to you, and how much of the surrounding work is yours. Those two questions are close to independent, which is why a badly chosen dedicated server can perform worse than a well-chosen VDS for the same money.

What the hypervisor actually does#

Underneath the marketing there are genuinely different technologies, and the difference shows up in what you can do.

Full virtualisation (KVM, VMware, Hyper-V, Xen HVM). The guest gets an emulated machine and runs its own kernel. You can load kernel modules, run Docker, set your own sysctl values, use any distribution, mount a swap file, and run a different kernel version from the host. This is what "a VPS" almost always means today, and it is what you want unless you have a specific reason otherwise.

Container virtualisation (OpenVZ, LXC, Virtuozzo). The guest shares the host's kernel. It is cheaper to run and denser, so it is cheaper to sell, but you cannot change kernel parameters, some sysctl settings are read-only, swap behaves oddly, and certain workloads - anything wanting kernel modules, some VPN configurations, occasionally Docker - do not work or work badly. Memory accounting is also looser, which is how a container VPS can be "out of memory" while free -m says otherwise. OpenVZ has faded but it has not vanished from the cheap end of the market.

Application containers (Docker, and therefore Pterodactyl-based game hosting). A different thing again, and not a VPS at all. One process tree per container, memory and CPU capped by the kernel's control groups, no kernel of your own and no root on the host. This is what a managed game or app plan is, and it is compared properly in VDS or a game panel.

Bare metal. No hypervisor. Every cycle and every byte of memory bandwidth is yours, including the ones you are not using.

A single command tells you which of these you are on:

$ systemd-detect-virtkvm$ systemd-detect-virt --containernone

kvm, vmware, microsoft or xen means full virtualisation. lxc, openvz or docker means you are sharing a kernel. none means bare metal, or a hypervisor that is hiding well.

"Dedicated resources" is three separate promises#

When a page says dedicated resources it may mean any of three things, and they are worth separating because only one of them is usually what people care about.

Dedicated memory. Your RAM allocation is backed by real memory and not overcommitted. This is common, cheap to provide and rarely the thing that goes wrong.

Dedicated CPU. Your vCPU are not shared with other tenants. On a shared VPS, eight tenants with two vCPU each can sit on a host with eight threads; when everyone is busy, everyone waits. On a properly dedicated CPU plan the mapping is closer to one vCPU per hardware thread and nobody else is scheduled on yours. This is the promise the letters VDS are meant to carry, and it is the one that most affects a game server, because a game server is one thread's worth of work that has to finish on time.

Dedicated disk and network. Far rarer than it sounds. NVMe drives are almost always shared through the same controller by every guest on the box, and the uplink is shared by definition. What good providers actually offer here is a queue-depth or IOPS limit per guest so that one noisy tenant cannot starve the rest.

The measurable consequence of a shared CPU is steal time: the percentage of time your vCPU was ready to run and the hypervisor gave the physical core to somebody else. It appears as the st column in vmstat and the %st figure in top:

$ vmstat 1 5procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 1  0      0 612344  84120 917640    0    0     3    14  201  388  9  2 88  0  1

Under 1% is normal and unavoidable. A sustained 5% or more on a plan sold as dedicated CPU means it is not. That is a number you can screenshot and put in a ticket, which is more than can be said for "it feels slow".

Shared CPU and noisy neighbours goes further into what a share guarantees and what it does not.

The physical machine, and what it really costs#

A dedicated server removes the hypervisor and the neighbours. What it does not remove is any of the work.

What you genuinely gain:

• All of the CPU, including the cache. On a virtualised host, neighbours evict your data from the shared L3 cache whether or not they are using CPU time you were promised. This is invisible in every benchmark that measures throughput and very visible in workloads sensitive to latency.
• Predictability. The 99th percentile of anything is better on a machine nobody else touches. For a game server, the 99th percentile is what players notice.
• Hardware choices. Specific drives, specific RAID, more memory than any VPS tier offers, sometimes a GPU.
• No overcommit, ever. Not because the provider promised, but because there is nobody to overcommit to.

What it costs beyond the monthly figure:

• Provisioning time. Bare metal is racked, imaged and handed over. That is hours to days, not minutes, and the same goes for a replacement when a drive dies.
• The whole sysadmin job. Same as a VDS, except that now the hardware is also yours to think about. RAID health, firmware, IPMI, a BIOS setting that reverted after a power cut.
• Idle capacity you paid for. A dedicated machine is sized for your peak. Everything above your average is money spent on being ready.
• A single failure domain. One machine is one machine. A VM can often be migrated to another host in minutes. A dead motherboard cannot.

The rule that holds up: take bare metal when you are actually going to use most of it, or when the 99th percentile is the product. Below that, a properly specified VDS is the same hardware with someone else responsible for the parts that are not your job.

RE:NODE's own line on the dedicated servers page is a VDS rather than bare metal, and the page says which machine it sits on: an Intel i9-9900K, with NVMe throughout on a ZFS pool, in Germany. That matters more than the category label. An i9-9900K is an eight-core, sixteen-thread part with a high single-core clock, which is exactly the shape of CPU a game server or a small database wants, and it is why the tiers stop at six vCPU: six of sixteen threads is a share that can be kept honest. Unlike the managed plans, which are created when payment clears and are usually running inside a minute, a VDS is prepared by hand and delivered within 24 hours.

Reading a spec sheet without being fooled#

The same six lines decide almost every comparison, and most listings answer two of them.

A concrete example of why the first row matters: four vCPU on a 2018 eight-core desktop part with a 5.0 GHz boost will beat four vCPU on a sixty-four-core server part clocked at 2.2 GHz for almost any game server, because the game server needs one thread to finish a tick on time and does not care about the other sixty. The same two machines reverse completely for a build farm or a web server handling many independent requests. A vCPU count with no model name attached cannot be compared with anything.

The second row is worth one follow-up question in a pre-sales ticket, because the answers differ: pinned cores means specific hardware threads are yours; a scheduler weight means you get a larger slice when there is contention, which is a different and weaker promise.

Which one fits which workload#

The pattern in that table is that virtualisation is almost never the deciding factor. What decides it is how many separate things you are running, how spiky they are, and whether you want the operating system to be your responsibility. How much a game server costs approaches the same decision from the money side, and several game servers on one VDS is the practical version of the second row.

Checking what you actually got#

Do this in the first ten minutes, before you install anything, and keep the output. It is the difference between a ticket that gets resolved and a conversation about feelings.

$ systemd-detect-virt            # kvm, lxc, openvz, docker or none$ lscpu | head -20               # model name, sockets, cores, MHz$ nproc                          # threads visible to you$ free -m                        # real memory, and whether swap exists$ df -h /                        # disk actually available$ uname -r                       # your kernel, or the host's

lscpu is the important one. It prints the model name, which turns "4 vCPU" into something comparable, and the Hypervisor vendor line confirms what systemd-detect-virt said. If the model name is blank or generic on a plan sold as dedicated CPU, ask why.

Then measure rather than trust. Single-core speed is the number that predicts game server behaviour, and sysbench gives a crude but comparable figure in ten seconds:

$ apt install sysbench fio$ sysbench cpu --threads=1 --time=10 run | grep "events per second"$ sysbench cpu --threads=$(nproc) --time=10 run | grep "events per second"

Run the single-threaded test three times at different hours. If the results vary by more than about 10%, you are sharing with somebody busy. For disk, a small random-write test is the one that matches what a world save or a database commit actually does:

$ fio --name=randwrite --ioengine=libaio --direct=1 --rw=randwrite \      --bs=4k --size=1G --numjobs=1 --runtime=30 --group_reporting

Look at the IOPS figure and at the 99th percentile latency, not at the average. What NVMe actually changes explains which operations that number governs and which it never touches.

Finally, watch steal time for a week with vmstat 60 piped to a file, or just glance at top at peak hours. On a container-virtualised plan steal time will read zero regardless, because throttling is accounted differently; check the control group instead:

$ cat /sys/fs/cgroup/cpu.statusage_usec 184203311nr_periods 291844nr_throttled 0throttled_usec 0

A climbing nr_throttled means you are hitting your own CPU limit, which is a sizing problem rather than a neighbour problem, and the fix is a bigger share or less work. CPU or RAM: which one is holding your server back is the method for deciding which.

Once you are satisfied with what you bought, spend the next half hour on the first hour on a new VDS: a non-root user, SSH keys, a default-deny firewall and unattended upgrades. A brand new box with password authentication is found by scanners within hours of its address going live, and that timeline is not an exaggeration.

FAQ#

Is a VDS just a VPS with a different name?

Sometimes. The intended distinction is that a VDS does not oversubscribe CPU or memory, so your share is genuinely yours. Nothing enforces the word, so treat it as a claim to verify: ask for the CPU model, ask whether cores are pinned, then measure steal time yourself for a week.

Do I need a dedicated server for a game server?

Almost never. A single game server uses one thread's worth of simulation and a few gigabytes of memory, which is a small fraction of any modern machine. Bare metal is worth it when you are running many servers at once, when you need every cycle of a fast core at the 99th percentile, or when you are reselling.

How many vCPU do I need?

Fewer than you think, and faster ones. Most game servers, most small web applications and most databases under real load are limited by how quickly one thread finishes its work. Two vCPU with a high clock beats eight slow ones for that shape of workload. Add cores when you are running several independent things, not to make one thing faster.

Can I run Docker on any VPS?

On KVM, VMware, Hyper-V or Xen, yes. On container virtualisation such as OpenVZ or LXC it ranges from awkward to impossible, because you do not control the kernel. Run systemd-detect-virt before buying anything where Docker is part of the plan, and prefer full virtualisation if you are unsure.

What happens when a VDS runs out of memory?

The kernel's OOM killer picks a process and terminates it, usually the largest, which is usually the thing you cared about. There is no warning and the evidence is in dmesg. Managed containers behave differently: the container is stopped at its limit and restarted clean rather than left to swap.

Is the hardware different between a VPS and a VDS?

Usually not. The same machines often serve both, and the difference is how many guests are placed on them and whether CPU is pinned. That is precisely why the CPU model and the overcommit policy are worth more than the product name on the page.