When you actually need 64 GB of RAM (and when 2 GB is enough)

"The server is slow, let's double the RAM" is the most expensive reflex in hosting. Sometimes it's right. Often the box is waiting on the disk, or the CPU is pegged, and the new memory sits there doing nothing while the bill doubles.

So before we talk about who needs 64 GB, let's work out what you're actually short of. If you just want typical memory numbers per workload, our earlier guide How much RAM does a VPS need has them, including the formula for language models. This piece is about diagnosis: RAM, disk or CPU.

Three commands, two minutes

Run these on the slow server while it's slow, not at 4 a.m. when nothing is happening:

free -m
vmstat 1 10
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io

Here's how to read them without a textbook.

free -m. Ignore the free column; Linux fills spare memory with disk cache on purpose. Look at available. If it's a few hundred megabytes on a 2 GB box and swap used keeps growing, memory is tight.

vmstat 1 10. Four columns tell most of the story:

A few non-zero si/so values once in a while are normal. Steady swapping every second is the real signal.

/proc/pressure/*. This is the most honest of the three. Each file shows the share of time tasks were stalled waiting for that resource. some avg60=25.00 on memory means that over the last minute, something was stuck waiting for memory a quarter of the time. Whichever of the three files has the biggest numbers is your bottleneck.

If it's the disk

High wa, high io pressure, little swapping. The usual cause is a database or log-heavy app reading more than fits in cache.

Here's the twist: more RAM can fix this, because Linux will cache more of the disk. If your database is 6 GB and the hot part is 3 GB, moving from 2 GB to 8 GB of memory can make the disk problem disappear. But if the database is 300 GB and every query touches a different part of it, no reasonable amount of RAM will cache it. Then the fix is better indexes, smaller queries or a different data layout. All plans here run on NVMe, so the disk itself is rarely the slow part. The access pattern usually is.

If it's the CPU

High us+sy, cpu pressure, no swapping, little waiting on disk. Compression, builds, video encoding, image processing, crypto math. More memory won't help at all.

Watch st too. On a VPS, a vCPU is a share of a physical core, not the whole core: the number in the plan is a ceiling for bursts, and sustained full load can be throttled to keep things fair for everyone on the machine. If your job needs all cores at 100% for hours, that's a workload problem, and we'd rather say so now than after you've bought a bigger plan.

If it really is RAM

Steady swapping, rising memory pressure, the out-of-memory killer in dmesg. Now the question is how much.

2 GB is enough, often for years, for: one bot or a handful of them, a small API, a VPN, a static site behind Nginx, a few cron scrapers, a monitoring agent. Micro gives you 2 vCPU, 2 GB and 25 GB for $5 a month on NAT, or $10 with its own IPv4.

4–8 GB is the comfortable middle: a web app plus its database, a small search index, headless browser automation, a couple of agents running side by side.

32–64 GB is for data that has to live in memory:

• a database whose working set is tens of gigabytes, so the cache actually holds the hot data;
• a large in-memory cache or queue that can't spill to disk without slowing everything down;
• a vector index for retrieval over millions of chunks (see self-hosted RAG at scale for real numbers);
• CPU-only inference of a mid-sized language model, where the weights must fit in RAM;
• consolidation: ten services that used to live on ten small servers.

That's what Pro-64 is for: 12 vCPU, 64 GB of RAM, 600 GB of NVMe and a dedicated IPv4 for $70 a month. The steps in between are Pro-32 at $40 and Pro-48 at $55; above it, Pro-80 at $90. Location availability for Pro plans is shown when you order.

Where a big box doesn't fit

Three cases where 64 GB is the wrong answer, even if you can afford it.

GPU work. None of these plans has a GPU. If your model needs one for training or fast inference, a CPU box with lots of RAM will run it, slowly, and you'll pay for patience.

Sustained full-CPU jobs. As above: vCPUs are burst capacity. Twelve of them at 100% around the clock isn't what a VPS is built for.

And "just in case". If the three commands show no memory pressure, the extra 60 GB is cache for files you don't read. Start smaller. Moving to a bigger plan of the same network type adds vCPU, RAM and disk in place with one reboot, as described in Changing your plan. Going down isn't possible in place, so buying too big has a real cost: to shrink, you migrate to a new server, and moving a VPS without downtime is a chore you'd rather not need.

If you're comparing plans across providers, how to read VPS specs explains what the vCPU, disk and port numbers actually promise.