How much RAM does WordPress need?

WordPress itself needs little memory, and its official requirements give no RAM figure. For a small site, 1-2 GB of RAM is usually a good starting point (a rule of thumb that varies with the site). Stores, many plugins and heavy traffic can push the need to 4 GB or more.

What you actually need depends on the kind of site: the plugins, the traffic, the size of the database and whether caching is on. This article covers the official numbers, what eats memory, and how to tell when it isn't enough.

What do the official requirements say?

The hosting requirements page on WordPress.org (an official recommendation) asks for PHP 8.3 or newer, MariaDB 10.11 or MySQL 8.0 or newer, and HTTPS support. It recommends Apache or Nginx as the web server. The page gives no figure for RAM. Older versions such as PHP 7.4 and MySQL 5.5.5 still run, but the page notes that they have reached end of life and carry security risks. On a new install, pick the recommended versions.

The only official memory numbers are the limits PHP grants to WordPress. On a single-site install, the default WP_MEMORY_LIMIT is 40 MB, and on multisite it is 64 MB. The admin area uses WP_MAX_MEMORY_LIMIT, and WordPress core tries to raise it to 256 MB by default. These are ceilings for a single PHP request, not the total RAM of the server. You can check the values that apply to your site under Tools > Site Health > Info: the PHP memory limit is listed in the Server section, while WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT appear in the WordPress Constants section.

What really uses the RAM?

• PHP processes. Every simultaneous request runs a PHP process. In PHP-FPM, pm.max_children limits how many can run at once (see the PHP manual). Depending on the plugins, one process can use anywhere from tens to hundreds of megabytes. That is a general observation and it differs from site to site.
• The database. MariaDB or MySQL keeps frequently read data in memory. Large, plugin-heavy sites want more.
• The operating system cache. Linux uses free memory as a disk cache. Seeing little free memory in the output of free -h is not a problem. Look at the available column instead.
• Cache layers. An object cache (such as Redis) reduces database queries, but it holds memory of its own.

Here is a simple example. On a server with 2 GB of RAM, if you set aside about 1 GB for the operating system and the database, 1 GB is left for PHP. If one PHP process uses 100 MB on average, keeping pm.max_children around 10 makes sense. These numbers only show how the calculation works. Your own measurements may come out differently.

Starting size by site type

These values are rules of thumb. They vary with plugins and traffic, and they are not a firm promise.

If you are building a store, also read our article "Choosing a server for WooCommerce".

What do you see when RAM runs out?

• The site returns a 502 or 503 error from time to time. PHP-FPM or the web server isn't able to answer.
• An "Error establishing a database connection" message appears. The database may have been stopped because memory ran out.
• The admin area becomes very slow, and plugin updates or image uploads stall halfway.

To confirm, connect to the server and run these commands:

free -h

sudo journalctl -k | grep -i -E "out of memory|oom-kill"

The second command lists the events where the kernel stopped a program because memory ran out. If it prints lines, RAM is not enough. In top, press Shift+M to see the processes that use the most memory.

What you can try before scaling up

1. Set up a page cache, either as a plugin or on the server side. A page served from cache runs neither PHP nor the database.
2. Remove plugins you don't use. Every active plugin loads its code on every request.
3. Tune pm.max_children in PHP-FPM to your memory. Roughly, divide the memory you can give to PHP by the average memory of one PHP process. A value that is too high eats memory under load.
4. A small swap area keeps the server from crashing during short spikes. But swap lives on disk and is slow, so it is no substitute for RAM.

If you have tried all of this and memory still fills up, it is time to scale up. Measure first: does the problem show up at peak hours, or all day long? As a general threshold, consider scaling up if the available memory often drops below 10-15 percent of total RAM at peak hours, or if swap is constantly in use. That is not a hard rule, only a starting point.

Scaling up from the panel

In the Seturack panel, you scale the server up with the slider on the Size tab. After payment the server restarts once on its own, and your IP address and data stay the same. That makes starting with a small size a safe route. A server with WordPress pre-installed is ready in roughly 3.5 to 4 minutes. Have a look at the WordPress server page.