Plan comparison tables encourage a bad habit: picking the row where the numbers look generous relative to the price. That tells you nothing about whether the machine fits your workload. Start from what you are running instead.
Match the resource to the bottleneck
Different workloads are constrained by different things. Identify yours before you look at any pricing page:
- Static sites and small blogs are bound by nothing much at all. Almost any plan is oversized, so buy the cheapest one and spend the savings on a CDN.
- WordPress and PHP applications are bound by single-core CPU speed and PHP-FPM worker memory. More cores rarely help. Faster cores do.
- Databases like PostgreSQL and MySQL are bound by RAM first and disk I/O second. You want the working set to fit in memory, which is where buying more RAM genuinely pays off.
- Game servers are bound by single-core performance and latency rather than core count. Minecraft in particular is close to single-threaded.
- CI runners and build machines are bound by core count and disk throughput. This is the one case where more vCPU is straightforwardly better.
- Media transcoding is bound by CPU across all cores and scales almost linearly with core count.
Size RAM from measurement, not intuition
If you are migrating an existing service, measure it. On the current machine:
free -h ps aux --sort=-%mem | head -15
Take the steady-state usage, add headroom for traffic spikes, then add a little more for the page cache. Linux uses free memory to cache disk reads, and a server with zero free RAM will feel slow even when nothing is swapping. As a rule of thumb, provision about 1.5x your measured steady-state.
Running out of RAM doesn’t slow your service down gradually. The OOM killer terminates a process, usually the largest one, usually your database.
Don’t under-buy storage
Disk is the resource people most often get wrong, because the number that matters isn’t the size of your data today. It is your data, plus the OS, plus logs, plus package caches, plus whatever local backups or database dumps you keep, plus enough free space that the filesystem doesn’t degrade.
A full disk takes services down hard: databases refuse writes, logs stop rotating, and package managers fail mid-upgrade. Keep at least 20% free at all times, and set up log rotation early.
Bandwidth is usually a non-issue until it is not
Ordinary web traffic consumes far less bandwidth than people expect. A page weighing 2 MB served 100,000 times is 200 GB. If you are serving video, large downloads, or acting as a file host, bandwidth becomes your primary cost driver and deserves real attention.
Start smaller than you think and scale up
Scaling up is a resize and a reboot. Over-provisioning from day one is money you spend every month for capacity you may never use. The exception is storage, which is more disruptive to grow on some setups than CPU or RAM, so be slightly generous there and conservative elsewhere.
Before you decide, run your actual workload on the smaller plan for a week and watch the graphs. Real usage data beats every sizing heuristic, including this one.