How Much RAM Does WordPress Need? 1GB vs 2GB vs 4GB

If you've shopped WordPress hosting in the last year, you've heard the same pitch: "you need at least 4GB of RAM for a serious site." Sometimes 8GB. Sometimes more. The pitch lands because RAM sounds like the thing that determines whether your site is fast or slow.

It mostly doesn't. The 4GB/8GB number is upsell, and it's hiding the actual math behind a vague gut-feel pitch.

Here's what's really going on, and how to figure out what your site actually needs.

The formula nobody tells you

WordPress core's own resident footprint is small relative to the workers running it — on the sites I've measured, single-digit megabytes of the per-request total. Idle plugin code costs little too. What dominates is PHP-FPM workers serving requests.

The formula:

Total PHP RAM = pm.max_children × RSS per worker

That covers the PHP tier, which is usually the largest single consumer. It is not the whole picture — the database, the OS file cache and any object cache each want real memory too, and I've broken those out below. The system RAM you need is this number plus your database server plus your web server plus a little headroom.

If you don't know what pm.max_children is yet, that's fine. We'll get there.

Finding your actual per-worker RAM

SSH into your server (any real VPS will let you), then run:

ps aux | grep php-fpm

You'll see a list of PHP-FPM processes with a RSS column (third from the right). That's the actual resident memory each worker is holding. For a warmed-up WordPress site:

• Plain blog, light plugin load: 40-70MB per worker
• Business site with a page builder (Elementor, Divi): 80-130MB per worker
• WooCommerce or membership site: 100-200MB per worker
• Heavy stack (Elementor + WPML + LearnDash + Woo): 200MB+ per worker, and getting nervous

Set memory_limit in php.ini (or in wp-config.php) to give each worker a ceiling. 256M for a normal site. 512M if you run Elementor or WooCommerce. Most "out of memory" white-screen bugs come from this being too low.

The plugin OOM trap

Stack too many plugins and a single worker can blow past its memory_limit mid-request. When it does, PHP-FPM kills the process and the user gets a white screen, a 500 error, or a half-rendered page.

This is the failure mode nobody warns new WordPress owners about. You install one more plugin, the site looks fine for a week, then under real traffic a worker peaks 50MB above the limit on a specific page and starts crashing intermittently. Hard to debug. Easy to prevent.

Two rules:

1. Don't install a plugin you haven't checked in a memory profiler (Query Monitor is the cheap option).
2. If you must install a plugin that bloats workers, raise memory_limit before you push to production.

Putting the system math together

Take a typical small business WordPress site. You set pm.max_children=10 (a sane default for a 2 vCPU VPS). Each worker runs at ~100MB. That's 1GB of PHP alone.

Add the database. MariaDB with default tuning sits around 256MB. Add the web server. Nginx is about 64MB. So before any traffic, your steady-state is around 1.3GB.

A 2GB VPS is the comfortable floor for this setup. You have ~700MB of headroom for OS page cache, request bursts, and the occasional plugin that spikes during a cron run. The 4GB number hosts quote is for sites with twice the workers or twice the per-worker memory, and most small sites don't need either.

The cache trick (with a caveat)

You can cut your PHP RAM math to almost nothing if you cache aggressively.

Full-page cache with W3 Total Cache or LiteSpeed Cache, plus a CDN in front (Cloudflare, Bunny), and most of your traffic never even hits PHP. Static HTML gets served from the edge, your origin sees a fraction of the requests, and your 2GB VPS feels like it has 8GB of headroom.

This is genuinely the biggest lever for shared-hosting-equivalent budgets.

The catch: it only works for static pages. Anything dynamic bypasses the cache:

• Logged-in users (the WP cookie flips the cache bypass)
• Carts and checkout (WooCommerce sessions are per-user)
• Member areas, forums, BuddyPress, LearnDash
• AJAX-heavy plugins

Those requests hit PHP every single time. So if your site is mostly anonymous content (a blog, a marketing site), 1GB with hard caching is fine. If it's mostly logged-in users (a community, a store, a learning platform), you're back to the per-worker math and you need the full 2GB+.

Shared and managed hosting

If you're on shared or managed hosting, all of this is academic. The host caps your memory_limit and decides your pm.max_children for you. You can't tune what you can't access.

Pick a plan that gives you at least a 256MB PHP memory_limit (512MB if you run a page builder or WooCommerce). Anything less is a foot-gun waiting to fire on your busiest day. The cheaper the plan, the lower the cap is usually buried in the fine print.

1GB vs 2GB vs 4GB: a decision table

Rough guidance based on the sites I've measured, not a guarantee. Your plugin stack moves these numbers, so treat it as a starting point to test against rather than a specification.

The pattern worth noticing: what moves you up this table is uncacheable traffic, not total traffic. A 100k-visit blog serving everything from page cache is comfortable on 1–2GB. A 5k-visit membership site where every request is logged-in is not.

PHP memory_limit is not your server's RAM

These get conflated constantly and they are different things.

• memory_limit is a per-request ceiling in PHP. Setting it to 512M does not reserve 512MB — it says a single request may use up to that before PHP kills it. It is a safety valve against runaway scripts.
• Total server RAM has to accommodate all concurrent workers at once, plus the database, plus the OS.

The failure mode is raising memory_limit to 512M on a 2GB server, then letting pm.max_children run high. Under load, enough workers legitimately claim their allowance and the server hits swap or the OOM killer. Raising memory_limit while leaving worker count untouched is what turns an occasional fatal error into a hard outage.

The memory the formula does not cover

Beyond PHP workers, budget for:

• Database buffer pool. MySQL/MariaDB's InnoDB buffer pool caches indexes and rows in memory. Default configurations are often conservative; a busy site benefits from more, and it comes out of the same total.
• Operating-system file cache. Whatever RAM you leave free, the kernel uses to cache files. This is not waste — a server with zero free memory has lost that cache and will read from disk more.
• Object cache (Redis or Memcached). Usually modest — tens of megabytes for most sites — but it is a separate process with its own footprint and eviction policy.
• Everything else. Web server, cron jobs, backup agents, monitoring, and whatever your host installed.

This is why "PHP needs 1.2GB so 2GB is fine" can still be wrong. The other consumers are real.

Logged-in versus cached visitors, and peak concurrency

The number that actually determines worker count is peak concurrent uncached requests, not monthly visits.

A page-cached request is served by the web server without touching PHP at all, costing almost nothing. A logged-in request bypasses the cache and occupies a worker for its full duration. So the calculation you care about is: at your busiest minute, how many requests are genuinely hitting PHP at the same time?

For most sites that number is far lower than the traffic figures suggest — which is why 1GB works more often than hosts imply. For stores and membership sites it is far higher relative to traffic, which is the real reason those workloads need more.

How I measured this

So you can judge the numbers rather than take them on faith: the per-worker figures here come from ps aux RSS readings on live sites running PHP 8.1–8.3 with PHP-FPM, WordPress 6.x, and plugin counts between roughly 15 and 40, under real traffic rather than synthetic load. RSS overstates somewhat because workers share copy-on-write memory with the parent, so treat these as a conservative upper bound.

That is a sample of production sites I have worked on, not a controlled benchmark. Run the command on your own server — the whole point of this article is that your number is measurable in about five seconds rather than guessable.

What this means for buying hosting

The "you need 4GB of RAM" advice is upsell. It might be the right answer for a busy WooCommerce store or a forum with hundreds of concurrent logged-in users, but for a typical small business WordPress site with a blog, 2GB is plenty, and 1GB with proper caching is enough.

If your site is slow and you suspect RAM, the first thing to check isn't your VPS plan, it's your ps aux | grep php-fpm output. The number is right there, and it's almost always smaller than you think.

If that same command shows workers stuck for minutes at a time, that's a different problem (stuck imports eating your worker pool) and we wrote it up separately: Site Goes Down Intermittently? Stuck Imports Are Eating Your PHP-FPM Pool.

If your WordPress site is slow and you'd like a second opinion on whether RAM is actually the bottleneck, we run a free 30-minute audit covering PHP-FPM tuning, plugin profiling, and cache configuration. Send a note to dino@helpwithweb.com with your URL.