How Much RAM Does a WordPress Site Actually Need?

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 itself uses almost no RAM. The plugins don't either, when they're sitting idle. What uses RAM is PHP-FPM workers serving requests.

The formula:

Total PHP RAM = pm.max_children × RSS per worker

That's it. Everything else (the WordPress install, the database schema, the plugin code on disk) is rounding error. The system RAM you need is just 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.

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.*