What to Look for When Buying a VPS

Why the specs sheet alone will get you a bad deal, and the six things that actually matter.

So you are about to rent a server. Maybe it is for a website, a Telegram bot, a small SaaS, or just somewhere to run your projects 24/7. The “specs” look tempting — 4 cores, 8 gigs of RAM, 100 gigs of disk — for almost nothing. But anyone who has run servers for a while learns the same lesson the hard way: the specs sheet tells you almost nothing about how fast the machine actually is.

Before you pay, here is what to check.

1. The CPU is not just core count

A “4-core VPS” can mean four modern AMD EPYC cores all to yourself, or one tiny slice of an ancient overloaded Xeon with nine other tenants hammering the same host.

• Look at the generation, not the core count. A 2013-era Xeon (like the E5-2660 v2) is several times slower per core than any current EPYC or Ryzen, even at the same clock speed.
• Run a single-threaded benchmark. Most everyday work — API backends, PHP, Node, databases — is far more sensitive to single-core speed than to core count. If two servers cost the same, take the one with the better single-thread score.
• Ask whether the CPU is shared or guaranteed. Some providers sell “CPU burst”: full speed for a minute, then a drop to half. A “20% CPU” line in the specs is a warning sign, not a feature.

2. RAM is honest, but check how you will actually use it

RAM is the one spec that rarely lies. If it says 4 GB, you get roughly 4 GB. But keep a few things in mind:

• A server with 4 GB and one slow core feels worse than one with 2 GB and a fast CPU. RAM is a capacity spec; CPU and disk are speed specs. Do not trade speed for size.
• No swap can be lethal. Redis, Postgres, or a busy Node app will kill a box with no disk-backed memory. Ask whether the plan includes swap at all.
• “DDR3” tells you the host is old. Old hosts are cheap for a reason — and their per-core CPUs are usually older and slower too.

3. Disk speed matters more than disk size — and almost nobody tests it

This is the biggest trap. A 100 GB disk can be:

• a spinning HDD shared with fifty other users (~100 MB/s, collapsing under load), or
• a fast NVMe (~2–3 GB/s) that makes database work feel instant.

The capacity is nearly irrelevant compared to the speed. A “100 GB SSD” that delivers 500 MB/s is not in the same universe as an “80 GB NVMe” doing 2.5 GB/s for the same price.

The differences really show up in random workloads — the small 4 KB reads and writes a database does constantly. These expose shared, hidden disks immediately. Ask for, or run, a random read/write test rather than just a sequential dd of a big file.

4. Network: the port speed is almost never what you get

“1 Gbps port” sounds great until you discover egress is capped at 100 Mbit/s, or the uplink is saturated at peak hours.

• Test in both directions. Upstream (upload from the server) is often throttled harder than download.
• Beware unmetered-but-throttled plans. “Unlimited” bandwidth at 30 Mbit/s is not a bargain.
• Latency is geography. If your users are in, say, Nepal, a server in Virginia half a second away can feel worse than one in Singapore 40 ms away, even with double the specs.

5. Oversubscription is the invisible spec

The real question is not “what does my VM have” but “how many other VMs share the hardware.” A provider selling hundreds of 4-core boxes off one host is selling the same CPU five times over.

Clues:

• Price that seems too good. (Sometimes it is genuinely just cheap — Hetzner and OVH are cheap AND fast because they own the hardware. Random budget resellers are another story.)
• No load-average or performance guarantee in the terms.
• Benchmarks that drop sharply between midday and midnight.

You can probe oversubscription yourself: run a CPU benchmark at 11 am and again at 11 pm. If the night numbers are 30–50% better, you are on a crowded host.

6. The boring operational facts

The unglamorous stuff decides whether you sleep well:

• Backups: does the plan include them, and can you restore without an engineer? The real price of a server is the price of losing everything.
• Public IPs: you generally want at least one IPv4 (they are scarce now), and IPv6 if the provider’s transit supports it.
• Support: will a human answer at 2 am, and in how long? For a hobby box this can be irrelevant; for a business it is the whole point.
• KVM/console access: if the box will not boot, can you fix it, or is a reinstall your only option?
• Exit fees: cancellations, data transfer off-site, and clone/export options matter if you ever want to leave.

Practical checklist

Before clicking buy:

1. lscpu — the model name, not just the core count. If it is ten years old, calibrate expectations.
2. free -h — the real RAM you will see in the VM.
3. After ordering, run a quick synthetic benchmark in the paid box before anything ties you down: single-thread CPU (sysbench cpu), memory throughput (sysbench memory), disk sequential AND random 4 KB (fio), network both directions (iperf3 to a public server).
4. Repeat the CPU and disk tests at a different time of day to sniff out oversubscription.
5. Keep the numbers. They are your baseline if the provider ever “accidentally” moves you to slower hardware.

One real-world example. Two boxes in the same inventory: a 4-vCPU AMD EPYC with mediocre ~550 MB/s disk, and a 2-core 2013-era Xeon with ~2.5 GB/s NVMe. Same ballpark price. The first crushes compute work; the second crushes database and file work. Neither is “better” — each is only worth buying for the workload it actually runs.

Bottom line

The best VPS purchase is rarely the one with the biggest numbers. It is the one whose CPU generation, disk speed, network cap, and oversubscription match the price. A $35-a-year box with fast NVMe but a ten-year-old CPU is a great deal if you need storage and not much compute; the same machine is a nightmare if you are running a database-backed API.

Buy the machine for the work it will actually do — and benchmark it like you mean it before you trust it.