You're standing on the cloud plan purchase page and you see two columns: one says "4 vCPU / 8GB RAM / 80GB SSD" and the other says "2 vCPU / 8GB RAM / 80GB NVMe". The price difference isn't small either. The real question is: which number becomes the bottleneck under real load? The short answer is that it's almost never the number you look at first.
What vCPU actually guarantees
A vCPU is not a physical core. It's a time-scheduled thread on a physical core. When a plan says 4 vCPU, it means the hypervisor allows your machine to have four parallel execution threads at any given moment. It doesn't guarantee that those four threads will always sit on four free cores.
On Linux you can see how many cores you actually have:
lscpu | grep -E '^CPU\(s\)|Model name|MHz'
nproc
cat /proc/cpuinfo | grep -c processorIf nproc returns 4 but lscpu under load shows the CPU model at a low frequency, you're probably dealing with shared cores. That's not bad; it just means you need to take steal time seriously:
top -bn1 | head -5
# look at the %st columnA %st value consistently above 5 percent means your machine is waiting for its CPU turn. Below 1 percent means the problem is elsewhere and upgrading vCPU is throwing money away.
When more vCPU actually helps
CPU-bound workloads: code compilation, high-volume TLS encryption, image processing, running small models. If load average is consistently higher than the number of vCPUs and %st is low, upgrading makes sense. If %st is high, the problem is in the neighborhood, not in the count.
RAM: the number that's always honest, but not in the way you think
RAM is dedicated. 8 gigabytes means 8 gigabytes, and this is the only number in the plan that has almost no ambiguity. But there are two points that in practice catch people off guard.
- Kernel buffer and cache RAM is counted separately. If you run
free -hand don't look at theavailablecolumn, you're reading the wrong number. Highusedwith highavailablemeans the system is healthy. - Swap on network storage is a disaster. If your plan has swap and it sits on shared storage, every swap-in is an I/O round trip. With
vmstat 1look at thesiandsocolumns; any consistent non-zero number means you're short on RAM, not CPU.
A rule of thumb that works in practice: for MySQL or PostgreSQL, size RAM so that innodb_buffer_pool_size is about 60 to 70 percent of total RAM. If you have a 4GB plan and the database wants a 3GB buffer, the web server and PHP-FPM have nothing left to breathe with. Here upgrading RAM is right, not upgrading CPU.
Disk type: where cloud plan specs don't lie but understate
"80GB SSD" is a capacity number, not a performance number. Two plans with identical capacity can differ tenfold in IOPS. You don't see that difference in the specs, you see it in iostat.
iostat -x 1 5
# look at the %util and await columnsIf await on the main disk is consistently above 20 milliseconds and %util is near 100, the problem isn't capacity; it's IOPS. NVMe under random load typically delivers several times the operations per second of SATA SSD, but under sequential load (like reading one large file) the difference is far smaller than the marketing claims.
| Disk type | Good for | Where it falls short |
|---|---|---|
| SATA SSD | Ordinary websites, log files | Databases with heavy random writes |
| NVMe | Databases, message queues, caches | Cost; and large sequential load |
| Network storage | Backups, archives, sharing between multiple servers | Anything that needs sub-millisecond latency |
Here's the mistake people make: the user upgrades the disk from SATA to NVMe because "the database is slow", but the slowness was from a query without an index. The tell is that after the upgrade, await drops but application response time stays the same. Run EXPLAIN ANALYZE first, then spend money on disk.
Traffic: monthly, inbound, outbound
Plan traffic is usually written as "X terabytes per month" and almost always means outbound. Inbound traffic is free with most providers because it isn't expensive for them. If your plan counts inbound too, check that in the contract, not on the sales page.
A practical note: measure traffic yourself with vnstat or iftop, not with the panel.
vnstat -m
iftop -i eth0 -nIf your outbound traffic keeps hitting the cap, you have two options: a plan with more traffic, or moving static files to object storage and serving them from a content delivery network. The second option at high volume is almost always cheaper, because CDN traffic is usually billed separately and doesn't pass through the origin server.
How to read a plan so you don't regret it later
- Before buying, measure your own real load. Log
vmstatandiostatfor a week. - Find the bottleneck: high
%stmeans CPU, non-zerosi/someans RAM, highawaitmeans disk. - Upgrade only the resource that is the bottleneck. Upgrading everything at once means paying extra for something you don't use.
- Before any change, take a snapshot. Snapshots in the cloud are the cheapest insurance you can buy.
One note about scaling: if you enlarge the plan, you usually need a reboot unless the provider supports hot-resize. For workloads that can't go down, ask this in advance. The guide on scaling cloud resources without downtime covers exactly this scenario.
And if your load grows horizontally (multiple web instances behind a load balancer) rather than vertically, the purchasing logic changes: instead of one giant plan, several medium plans with a load balancer and health check is usually both cheaper and more resilient. For containerized workloads, managed Kubernetes does this for you.
Frequently asked questions
Is vCPU shared or dedicated?
In most cloud plans, vCPU is shared; meaning your execution threads are scheduled on shared physical cores. If a plan has "dedicated" or dedicated CPU, this is stated in the specs and its price is usually higher too. To tell in practice, look at the %st column in top; if it's consistently above 5 percent, your actual share is less than the plan's number.
Why is the server slow even though I have enough RAM?
Because the bottleneck is elsewhere. Three main candidates: high %st (short on CPU share), high disk await (short on IOPS), and queries without indexes. With vmstat 1 and iostat -x 1 you can rule out or confirm all three in two minutes. Upgrading RAM when si and so are zero doesn't improve anything.
Does the plan's monthly traffic include inbound too?
With most providers only outbound is counted and inbound is free, but this is a contract, not a technical law. If your workload is inbound-heavy (for example receiving uploads or log ingest), read this clause in the contract. Independent measurement with vnstat -m on the server is a more reliable reference than the panel.
Is NVMe always better than SSD?
No. Under heavy sequential load (reading and writing large files) the difference between NVMe and SATA SSD is far smaller than under random load. NVMe is worth it when random IOPS is the bottleneck: databases, message queues, caches. If the bottleneck is queries or CPU, upgrading the disk is just cost.
Next step: before any upgrade, collect a week of vmstat and iostat logs and see which column is red. If you're still not sure which resource is the bottleneck, the guide on cloud monitoring and alerts is the right starting point; after that, choosing a plan becomes an engineering decision rather than a guess.