How Much RAM Does a WordPress Site Actually Need on a VPS?

RAM is the spec most people guess at when choosing a VPS plan, because unlike storage, it is hard to picture in concrete terms before the site is actually running. 75GB of disk is easy to reason about; you know roughly how big a WordPress install and its media library are. 4GB versus 8GB of RAM is a much harder call to make in advance, and the cost difference between getting it wrong in either direction is real: an undersized plan means random crashes under load, and an oversized one means paying monthly for headroom that never gets used.

The answer depends on what is actually running on the server, not just WordPress in the abstract. Here is what consumes memory on a typical WordPress VPS, in the order it usually adds up.

The Operating System's Baseline

Ubuntu Server itself, with nothing else running, uses somewhere between 200MB and 400MB of RAM at idle. This is not optional overhead you can tune away; it is the cost of the kernel, systemd, and basic system services just existing. On a 4GB VPS this is a small fraction of the total, but it is worth knowing it exists before assuming every megabyte of a plan's RAM is available for WordPress and its supporting services.

PHP-FPM: The Biggest Variable

PHP-FPM is where most of WordPress's memory actually gets consumed, and it is also the setting most people leave at whatever default their install shipped with rather than sizing deliberately. Each PHP-FPM worker process loads independently and typically uses 40MB to 80MB of memory depending on how many plugins are active, since every active plugin's code gets loaded into every worker. A default pm.max_children value of 50, common in unmodified configs, tries to allow 50 concurrent workers; at 60MB each that is 3GB of RAM reserved for PHP alone, which does not fit inside a 4GB plan once the OS, MySQL, and everything else is accounted for.

The correct number of workers is not a fixed value; it is RAM available for PHP divided by average memory per worker, calculated for the specific server rather than copied from a tutorial. The [guide to tuning PHP-FPM and OPcache](https://arcadiaservers.com/blog/tune-php-fpm-opcache-wordpress-vps) walks through calculating pm.max_children correctly for a given amount of RAM, and getting this number wrong in either direction is the single most common cause of a WordPress VPS running out of memory under real traffic.

MySQL or MariaDB

The database process itself typically uses 200MB to 500MB at rest on a small to medium WordPress site, and that number climbs with the size of innodb_buffer_pool_size, a setting that controls how much of the database MySQL keeps cached in memory rather than reading from disk on every query. A larger buffer pool means faster queries, since more of the working data set stays in RAM, but it directly competes with PHP-FPM for the same finite memory, and on a 4GB VPS there is not much room to raise it aggressively without starving PHP of workers instead.

Object Caching, When Used

Redis, if configured as an object cache, typically uses 50MB to 200MB depending on how much data ends up cached, which for most WordPress sites is a worthwhile trade: it reduces the number of database queries MySQL has to serve, which in turn reduces MySQL's own CPU load. The [guide to setting up Redis object caching](https://arcadiaservers.com/guides/set-up-redis-object-cache-wordpress) covers configuring it correctly, and on a 4GB plan it is worth budgeting for even though it adds a modest amount of baseline memory use, since the database load it removes elsewhere usually outweighs that cost.

Putting the Numbers Together

For a single WordPress site with moderate plugin usage and typical small business traffic, a realistic breakdown on a 4GB VPS looks like 300MB for the OS, 1.5GB to 2GB for a correctly sized PHP-FPM pool, 300MB to 500MB for MySQL, and 100MB for Redis if used, leaving a reasonable buffer for traffic spikes and swap to absorb anything unexpected. That fits Arcadia's Essential plan, 4GB of RAM and 2 vCPUs, comfortably for one site running WordPress with a normal plugin count.

The picture changes with anything that adds real load: WooCommerce, which runs additional queries per page and typically needs more PHP-FPM workers to handle checkout concurrency; a second or third WordPress site sharing the same server, each with its own PHP-FPM pool and, ideally, [its own isolated database](https://arcadiaservers.com/blog/multiple-wordpress-sites-vps-nginx-server-blocks); or genuinely high traffic, several thousand daily visitors, where more concurrent PHP-FPM workers are needed to serve requests without queuing. Any of these push the realistic minimum toward 8GB, Arcadia's Standard plan, rather than 4GB.

Signs You Have Undersized the Server

The clearest sign is the Linux out-of-memory killer terminating processes under load, visible in the system log as a process, often mysqld or a PHP-FPM worker, being killed specifically because the kernel ran out of memory to allocate. A slower but equally telling sign is a site that works fine at low traffic and becomes inconsistently slow or briefly unresponsive during traffic spikes, which usually means PHP-FPM is queuing requests behind a pm.max_children limit set too low for the RAM available, rather than the server genuinely lacking the CPU to keep up.

Frequently Asked Questions

Is 2GB of RAM enough for WordPress?

It can run a single low-traffic WordPress site with a minimal plugin count, but the margin for error is thin: a single traffic spike, a plugin update running in the background, or a slightly generous PHP-FPM setting can push memory usage past what is available. 4GB gives enough headroom that a normal WordPress install does not require unusually careful tuning just to stay stable.

Does more RAM make WordPress faster?

Only up to the point where RAM was the actual bottleneck. Extra RAM beyond what PHP-FPM, MySQL, and caching can meaningfully use does not make individual page loads faster; a single visitor's page load is bound by PHP execution time and database query speed, not by how much unused memory happens to be sitting idle. Where RAM matters most is concurrency, how many simultaneous requests the server can handle without queuing, not the speed of any one request in isolation.

Should I upgrade RAM or optimise PHP-FPM settings first?

Check pm.max_children against actual available RAM before upgrading anything. A very common situation is a server with enough RAM for the traffic it receives, but a PHP-FPM pool configured with a default value that was never adjusted for the server's actual memory, either too high, causing memory exhaustion, or too low, causing requests to queue unnecessarily. Correcting that costs nothing and often resolves the problem outright; upgrading the plan is the right move once the pool is already sized correctly and the server is still running short on memory under real load.