Of the three numbers on a cloud plan — vCPU, RAM, disk — memory is the one that fails hardest when you get it wrong. A server short on CPU is slow. A server short on memory stops.
What actually consumes memory
On a typical application server, in rough order of appetite:
- The database. Postgres and MySQL both try to keep the working set of your data in memory. This is not waste; it is the difference between a query hitting RAM and hitting disk.
- The application runtime. Each worker process or thread pool costs memory, and the total is workers × per-worker footprint, which is where people miscount.
- The cache. Redis or Memcached hold exactly as much as you let them, so an unbounded cache is a memory leak with a nicer name.
- The operating system’s page cache. This looks like used memory in naive tools and is actually reclaimable. Reading “free” output incorrectly is the most common sizing mistake there is.
What being short of memory looks like
It rarely announces itself as “out of memory”. The usual sequence is:
- The system starts swapping. Latency becomes erratic rather than uniformly slow — some requests are fine, some take seconds.
- Disk I/O climbs for no application reason, because swap is disk.
- The kernel’s out-of-memory killer terminates the largest process. On most servers, that is the database.
- The service restarts, memory frees, and everything looks healthy again — until the next time.
An intermittent, unexplained restart of the biggest process on the box is a memory problem until proven otherwise.
Measure rather than estimate
Estimating memory from a stack diagram does not work, because the answer depends on your data and your traffic. The method that does work:
- Deploy on a modest instance.
- Run real traffic — or a realistic replay of it — for at least a full daily cycle, ideally a week.
- Watch available memory, not used memory, and watch swap activity rather than swap size.
- Size so that the peak leaves comfortable headroom, then stop.
Headroom matters because memory demand is spiky in ways CPU demand is not. A single large import, a backup, or one unusually expensive query can double the footprint for a minute.
Useful rules of thumb
These are starting points to measure against, not specifications:
- A small static or brochure site is disk-bound and network-bound, not memory-bound.
- A dynamic application with a local database wants enough memory for the database’s working set plus the app, not just the app.
- Anything running containers should budget for the orchestration layer as well as the containers.
- Build servers and CI runners are memory-hungry in bursts, and the burst is what you must size for.
- Machine learning inference is often memory-bound before it is compute-bound — see running LLM inference on your own cloud account.
Should you configure swap?
A small swap file is a useful shock absorber: it turns a hard out-of-memory kill into a period of degraded performance you can be alerted about. It is not a substitute for memory. If a server is steadily swapping, it is too small, and no amount of tuning changes that.
Resizing is cheaper than over-provisioning
On every cloud platform in this catalogue, moving to a larger instance is a resize and a reboot — minutes of downtime, scheduled when you choose. Paying for double the memory you use is a cost you carry every month forever. Start small, measure, resize once.
If the workload’s memory demand varies enormously by time of day, that is an argument for autoscaling rather than for a permanently larger machine.
Where to go next
- What vCPU actually means on a cloud account
- Monitoring a cloud server without a large observability stack
- Browse configurations — every listing shows its vCPU and memory
Questions
Frequently asked
Is more RAM always better on a cloud server?
Only up to the point where the workload stops swapping and has headroom for spikes. Beyond that you are paying every month for memory the operating system will use as page cache and nothing more.
How do I know if my server is short on memory?
Watch swap activity and the kernel log. Steady swap-in and swap-out under normal traffic, or an out-of-memory kill in the system log, both mean the instance is undersized.
Can I add RAM to a cloud server later?
Yes. On every provider in this catalogue that is a plan change followed by a reboot, which is why starting smaller and measuring is the cheaper approach.