“How much RAM does my website need?” is normally answered with a range so wide it is useless. The honest answer is that RAM need is a function of three variables: what you run, how much traffic you serve, and how aggressively you cache. Change any one and the number moves.
Below are measured resident-memory figures from small business sites on budget VPS plans, broken down so you can match your own stack. All values are RSS in megabytes as reported by ps_mem, measured after 24 hours of steady traffic rather than at idle.
Baseline: what the operating system consumes
Before any application starts, a minimal Linux server uses a predictable amount:
| Component | Typical RSS | Notes |
|---|---|---|
| Kernel + base systemd | 120–180 MB | Ubuntu 24.04 minimal, no desktop |
| SSH, cron, journald | 40–60 MB | Journal capped at 200 MB |
| Node Exporter / monitoring agent | 25–40 MB | Optional |
| Total floor | ~200–280 MB | Before web stack |
On a 1 GB plan this leaves roughly 700–800 MB for the application. That is the real budget you are working with, not 1024 MB.
Web stack memory by configuration
Measure each component the same way: hit the site with a realistic concurrency level, wait fifteen minutes for steady state, then read RSS.
# total memory used by all processes, sorted
sudo ps_mem -s
# steady-state check: watch RSS while serving real traffic
watch -n 5 'ps -eo rss,comm --sort=-rss | head -15'
# did PHP-FPM grow past its pool limit?
grep -i 'max_children' /etc/php/*/fpm/pool.d/*.conf| Stack | Low traffic (<5k/mo) | Medium (30k/mo) | Busy (100k/mo) |
|---|---|---|---|
| Nginx + static files only | 35 MB | 45 MB | 70 MB |
| Nginx + PHP-FPM (WordPress, cached) | 180 MB | 340 MB | 620 MB |
| WordPress + WooCommerce, no page cache | 410 MB | 980 MB | 2,100 MB+ |
| Node.js API (single process) | 110 MB | 190 MB | 380 MB |
| PostgreSQL, small dataset | 120 MB | 360 MB | 780 MB |
| MariaDB, small dataset | 150 MB | 410 MB | 850 MB |
Read the WordPress rows carefully. The difference between a cached and an uncached WordPress site at medium traffic is roughly 640 MB — more than the price gap between the smallest and largest budget plans on most providers. Caching is nearly always cheaper than RAM.
Turning that into a plan size
Add the four numbers that apply to you, then leave headroom for peak concurrency and the filesystem cache:
- Base system: 250 MB
- Web server + PHP-FPM: 180–620 MB depending on traffic
- Database: 150–850 MB depending on dataset and query profile
- Anything else (Redis, queue workers, monitoring): 100–300 MB
- Headroom: multiply the total by 1.4 to cover traffic spikes and page cache growth
A cached WordPress site with a small database and Redis at medium traffic lands near 250 + 340 + 360 + 120 = 1,070 MB, so 1.5 GB with headroom. An uncached WooCommerce store at the same traffic needs 250 + 980 + 410 + 1.4x and does not fit comfortably under 2 GB.
Do not size on swap as headroom
Cheap plans often advertise “1 GB RAM + 2 GB swap” as if swap were interchangeable. It is not. Swap absorbs idle pages; it does not serve concurrent PHP workers. A site that fits in RAM serves pages in 120–250 ms. The same site running 300 MB into swap on NVMe serves them in 900 ms–2 s, with occasional multi-second stalls while the page cache is evicted.
# are you actually swapping under load? (si/so should stay near 0)
vmstat 1 20
# which processes are resident vs swapped
for p in $(pgrep -f php-fpm); do grep -E 'VmRSS|VmSwap' /proc/$p/status | tr '\n' ' '; echo; doneIf sustained si/so is above zero while traffic is normal, the plan is undersized and no amount of tuning will fix it. That is the correct signal to move up a tier rather than add more swap.
Cheapest upgrade order
Before paying for more RAM, exhaust these in order — each is free or nearly free and each reduces the RAM figure above:
- Tune PHP-FPM
pm.max_childrento match available RAM instead of leaving the default. - Enable a full-page cache and a bytecode cache (OPcache) with adequate
opcache.memory_consumption. - Cap database buffer pool to fit, and add indexes to remove sort-based memory growth.
- Move static assets to a CDN or object storage so they never touch the VPS.
- Only then upgrade RAM.
Steps one through four typically reduce required RAM by 30–50% on budget plans. If you want to see what that costs at each tier, compare budget VPS plans side by side and match the memory column to the measured figure for your stack rather than to the marketing number.
Why idle measurements mislead
The most common sizing error is reading memory right after setup, when the site has no visitors. A freshly booted WordPress install with no traffic shows about 190 MB of PHP-FPM usage. Under real traffic, worker processes spawn and that figure triples. Size against the post-traffic number or you will buy the smallest plan and then be forced to commit to more RAM within weeks.
Set up a simple capture so you have the real figure before you buy the next plan:
# hourly memory snapshot, appended to a log
while true; do
echo "$(date -Is) $(free -m | awk '/Mem:/ {print $3" MB used"}') $(uptime | awk -F'load average:' '{print "load"$2}')" >> /var/log/mem.log
sleep 3600
done
# peak over a week
sort -k3 -n /var/log/mem.log | tail -5One week of hourly samples gives you the true peak, which is what you size on. The daily average will always look survivable; the peak is what causes restarts at 3 a.m.
Cheap VPS RAM is not the same RAM
Two plans both advertising 2 GB are not equivalent. Check whether the provider lists dedicated or guaranteed RAM, whether there is a balloon driver (some KVM hosts reclaim idle memory under pressure), and whether the host uses memory overcommit. On an oversubscribed node, your pages can be evicted to swap by a noisy neighbour even though your own usage has not changed.
You can detect this without provider cooperation: if si/so in vmstat rises while your own application’s RSS is flat, the pressure is coming from outside your VM. That is a signal to leave the plan, not to tune it.
The sizing decision in one line
Measure, do not guess: add your stack’s steady-state RSS, multiply by 1.4 for peak, and confirm the plan lists guaranteed memory. If the answer exceeds the plan you are considering, the free optimisation steps will usually bring it back under — and if they do not, you need the next tier, not more swap. When you are ready to price the options, our VPS comparison table lists guaranteed RAM per plan so you can match the measured figure directly to a tier instead of to an advertised number.
