Picking a VPS feels like buying a laptop: bigger numbers seem safer. But servers fail in a specific order under load, and knowing that order saves you money.
RAM is what bites first
For most web workloads, you run out of memory before you run out of CPU. A database, an app runtime, and a cache all want RAM, and when it's gone the kernel starts swapping to disk — which feels like the whole server died. Size RAM for your working set first; treat vCPU as secondary unless you know you're CPU-bound.
When CPU actually matters
- Build servers and CI runners — compilation is CPU-hungry.
- Media transcoding and image processing.
- High-concurrency APIs doing real computation per request.
If your app is mostly waiting on a database or the network (the common case), more cores won't help. One or two vCPU with enough RAM beats four starved cores.
SSD: size and speed
NVMe SSD is standard now and the capacity number is usually generous. The thing to watch isn't gigabytes — it's whether your database's working set fits in RAM, because once it spills to disk even fast NVMe is orders of magnitude slower than memory.
A starting map
- 01Side project / small site: 1 vCPU, 2 GB RAM is plenty.
- 02Small production app + database: 2 vCPU, 4 GB RAM.
- 03Busy app, multiple services: 4 vCPU, 8 GB RAM.
- 04Heavy workloads / many containers: 8 vCPU, 16 GB RAM.
Buy the tier that fits today plus a little headroom, prepaid for the year. Over-buying "to be safe" is the most common — and most expensive — VPS mistake.
