How Much RAM Do You Actually Need for Multiple WordPress Sites on One VPS?

Every hosting company sells VPS plans by the number of websites you can host. “Up to 10 sites”, “unlimited sites”. It is the wrong unit, and it is why so many people buy a plan that fails under the first burst of real traffic.

A website with no visitors costs you almost nothing. What consumes memory is not the site. It is the number of visitors being served at the same moment.

I run seven WordPress sites on one small server. Here is what they actually consume, measured, and how you can work out the number for your own setup instead of guessing.

The machine, and what it holds

The server is modest on purpose: 2 virtual CPUs, 3.9 GB of RAM, a 39 GB disk — the disk is only 31% full, which tells you immediately that storage is not the constraint people think it is.

On it: eight site configurations, seven of them WordPress, plus the database. It has been running these sites for months, and it goes weeks between restarts.

That is not a big machine. It is the size most people start with, and the size most people outgrow without understanding why.

Why “how many sites” is the wrong question

When someone visits a WordPress page, a program called PHP builds that page from scratch: it asks the database for your content, runs the theme, runs every active plugin, and produces the HTML the browser receives. That work happens in a worker process, and each worker holds memory while it works.

Crucially, workers are shared across every site on the server. Ten sleeping sites use no workers at all. One site with thirty simultaneous visitors can use all of them.

So the real formula is not sites × memory. It is:

(number of simultaneous workers  ×  memory per worker)  +  database  +  operating system

Every one of those terms is measurable. None of them is guessable.

My measured numbers

Here is where it becomes uncomfortable, and useful.

Memory per worker: 170 MB. Measured, not estimated. A lean WordPress install typically sits around 40-60 MB per worker. Mine is roughly three times that, and the reason is entirely identifiable: a heavy commercial theme, a page builder, and a security plugin, all loading on every single request.

Database: 416 MB. Steady, and it grows slowly with content.

Operating system and web server: roughly 300 MB.

My worker ceiling is set to 12. So the arithmetic at full load is:

12 × 170 MB   = 2040 MB   workers
              +  416 MB   database
              +  300 MB   system
              = 2756 MB   out of 3915 MB

That fits, with about 1.1 GB of headroom. It works — but the headroom is thinner than it looks, and I know exactly why.

The number that moves while you are not watching

Twelve days before that measurement, the same workers averaged 137 MB. Now they average 170. Nothing dramatic happened: plugins updated, content grew, the theme did what heavy themes do.

At 200 MB per worker — entirely plausible on the same trajectory — the same configuration needs 3.1 GB, and the machine starts using the disk as overflow memory. That is called swapping, and it is worse than it sounds: the site does not fail, it becomes slow. Failures are easy to diagnose because something visibly breaks. Slowness gets blamed on the internet, on WordPress, on the visitor’s phone, on everything except the actual cause.

The lesson: memory per worker is not a constant you look up once. It is a moving number on your own machine, and it only moves upward.

How to measure yours

If your server runs PHP-FPM (nearly all do), one command gives you the real figure:

ps -o rss= -C php-fpm8.2 | awk '{s+=$1; n++} END {printf "%d workers, avg %.0f MB\n", n, s/n/1024}'

Replace php-fpm8.2 with your version. Run it while the site is busy, not at three in the morning — you want the number under load, not at rest.

For the database:

ps -o rss= -C mariadbd -C mysqld | awk '{s+=$1} END {printf "database: %.0f MB\n", s/1024}'

And for the whole picture:

free -m

Three commands. They take a minute and they replace every estimate in every hosting comparison article, including this one.

The two ways to get it wrong

Setting the worker ceiling too low. The server refuses new work once every worker is busy, and visitors get a 502 Bad Gateway error. It looks like your host is failing. It is not: it is a number in a configuration file. My own ceiling was originally 5, which was far too low for seven sites, and the whole server produced intermittent 502s for months.

Setting it too high. The server accepts more simultaneous work than its memory can hold, starts swapping, and everything becomes treacle. This is the mistake people make immediately after discovering the first one, because raising the number did fix the 502 and it is tempting to assume more is better.

The correct ceiling is not a preference. It is:

(total RAM − database − system − a safety margin) ÷ memory per worker

For my machine: (3915 − 416 − 300 − 400) ÷ 170 ≈ 16. I run 12, deliberately below the maximum, because the per-worker figure drifts upward and I would rather have the margin than the capacity.

So what should you actually buy?

Work out your own number first, then read plans in that unit.

If your measured worker is lean (40-60 MB), a 2 GB server comfortably handles a real amount of traffic, and 4 GB is generous. Most people in this position are being oversold.

If your measured worker is fat (150 MB and up), as mine is, you are paying for your theme in RAM every single day, forever. Before buying a bigger plan, work out what the theme costs you: dropping from 170 MB to 60 MB per worker would nearly triple my capacity on the same machine, at no extra cost. That is the cheapest upgrade available to me, and I have not taken it yet because replacing a theme means rebuilding the site.

If you do not want to manage any of this, that is a legitimate answer rather than a defeat.

Managed WordPress hosts like Kinsta handle worker limits, PHP versions and scaling as part of the product, and price by traffic rather than by RAM — which, as this whole article argues, is the more honest unit. You pay considerably more per month and you stop having conversations about pm.max_children entirely.

If you want to keep control and pay very little, providers like Hostinger and Contabo sell VPS plans where an extra gigabyte of RAM costs less per month than the hour you would spend tuning around not having it.

VPS plans in the 2-8 GB range at prices where over-provisioning costs less than getting it wrong. Given how much memory drifts upward over time, buying one size above your calculation is a rational decision rather than a wasteful one.

For the record: I run on neither. My server is with an Italian provider I have used for years for unrelated business reasons, and it has no affiliate programme, so I have nothing to gain by recommending it and no reason to hide it. What I do have is the measurements above, taken from that machine, which is more than most comparison pages can say.

The short version

• Sites do not consume memory. Simultaneous visitors do.
• Measure memory per worker on your own server. Do not use anyone’s published figure, including mine.
• Multiply by your worker ceiling, add the database and the system, compare with your total RAM.
• Re-measure every few months, because the number grows.
• Too few workers gives you visible errors. Too many gives you invisible slowness, which is worse.

Once you have your own number, the plan you need stops being a marketing decision and becomes arithmetic.