What Is a VPS? Definitions, Specs, and How to Tell One Provider From Another

Every provider sells a “VPS” with the same words on the pricing page: 2 vCPU, 4 GB RAM, 80 GB NVMe. Those labels hide the differences that actually determine performance. Two 2-vCPU instances can differ by 3x in real throughput depending on how the host oversubscribes cores, throttles disk, and caps network bursts. This guide defines what a VPS really is, decodes the spec sheet, and gives you the commands to tell one provider from another before you commit money.

What a VPS Actually Is

A VPS is a guest virtual machine running on a hypervisor (almost always KVM in 2026, occasionally Xen or a container-based LXC/OpenVZ setup). The hypervisor carves physical resources — CPU, RAM, disk, NIC — into virtual ones and hands them to your guest. You get a kernel, root access, and an isolated filesystem. What you do not automatically get is a guarantee that the physical resources behind those virtual numbers are reserved for you.

Container-based “VPS” plans take this further: they share the host kernel entirely, so your RAM, IO, and process limits are enforced by cgroups rather than hardware virtualization. They are cheaper and faster to provision, which is why the cloud VPS approach is popular for burstable workloads.

The practical consequence is simple: two “2 vCPU / 4 GB” plans can differ by 2-3x in sustained real-world throughput while carrying identical labels. The label describes the virtual allocation; only your own benchmark reveals the physical backing behind it.

Decoding the Spec Sheet

Term	What it says	What it actually means
vCPU	1 virtual CPU	1 hardware thread, possibly shared with others
Dedicated vCPU	Reserved core	Pinned thread, no steal — verify it
NVMe storage	Fast disk	Shared NVMe with an IOPS cap
Unmetered bandwidth	No transfer limit	Port capped at 100 Mbps or 1 Gbps
4 GB RAM	Memory	May be overcommitted via KSM/ballooning

The Specs Providers Do Not Print

• Oversubscription ratio: how many vCPUs are sold per physical core. 1:1 is a VDS; 4:1 is aggressive.
• IOPS ceiling: the hard cap on disk operations, enforced per-instance, often around 2,000-3,000 IOPS on budget tiers.
• CPU steal baseline: the percentage of cycles you lose to neighbors on an idle day.
• Network burst policy: whether you get a sustained 1 Gbps or a 100 Mbps port with short bursts.

How to Tell One Provider From Another: Seven Commands

Run these on any trial instance. They take five minutes and reveal more than any sales page.

# 1. CPU model and whether you get real dedicated threads
lscpu | egrep 'Model name|CPU\(s\)|Thread|Hypervisor'

# 2. Are you on bare metal KVM or shared containers?
systemd-detect-virt

# 3. Memory you actually get (watch for ballooning)
free -h; cat /proc/meminfo | grep -i committed

# 4. Disk type and real throughput
lsblk -d -o NAME,ROTA,SCHED; fio --name=t --rw=randread --bs=4k --iodepth=32 --runtime=20 --timeout=20 --output-format=terse | cut -f8,9

# 5. Steal time under load
sysbench cpu --threads=$(nproc) --time=30 run & vmstat 1 10 | awk 'NR>2 {print \"st%:\", $15}'

# 6. Network port speed
curl -s -o /dev/null -w '%{speed_download}\n' https://speed.cloudflare.com/__down?bytes=200000000

# 7. Kernel and uptime of the host (from your guest, via steal correlation)
uptime; cat /proc/loadavg

Read the results together. A 4 vCPU plan that shows 12% steal under load is really a 3.5 vCPU plan. A “1 Gbps” port that never exceeds 90 Mbps in the download test is a 100 Mbps port. This is the difference between two providers selling the identical spec sheet.

Benchmarking Fairly Across Providers

Single runs lie. Run each test three times at different hours of the day — a quiet 3 a.m. host and a contended 3 p.m. host are different products. Normalize results per vCPU and per dollar so a $20 plan and a $60 plan can be compared on cost-efficiency rather than raw numbers.

Questions to Ask Before You Buy

• Is the vCPU dedicated or shared, and what is the oversubscription ratio?
• What is the enforced IOPS cap on my plan, and are burst credits available?
• Is RAM guaranteed or overcommitted?
• What happens when I exceed a limit — throttle, or suspend?
• Can I run my own kernel and modules (KVM) or not (containers)?

The Specs That Are Not on the Sheet

Two providers with identical hardware can still deliver very different experiences, because the real differences live in operations rather than in specs.

• Snapshot and backup model: hourly automated snapshots versus manual DIY. Run an actual restore before you trust it.
• Support first-response: a hardware fault at 2 a.m. feels very different when the answer arrives in 15 minutes rather than 6 hours.
• Network peering and route quality: run mtr -rwzbc 100 1.1.1.1 from your instance. Latency and paths vary far more than the spec sheet implies.
• Data-transfer wording: “unmetered” almost always means a rate-limited port, not unlimited throughput.

These operational details are what separate a plan that merely looks identical on paper from one that is genuinely worth running production traffic on. Pair your benchmark numbers with real-world reliability evidence before committing to an annual contract.

Finally, benchmark the provider’s own control panel and API: how quickly you can rebuild, resize, or snapshot an instance is part of the product. A slow API turns a five-minute recovery into a forty-minute outage, and no spec sheet advertises it.

Takeaway

A VPS is not a spec sheet — it is a set of hidden allocation policies. The numbers on the pricing page tell you the ceiling; the commands above tell you the floor you will actually experience. Before committing, benchmark a candidate plan against these checks, and browse the available VPS configurations with the verified specs you now know how to read.