Short answer: most single WordPress sites run fine on a VPS with 1–2 GB of RAM. A small WooCommerce store usually needs 4 GB, and busy stores or high-traffic sites land around 8 GB. Those are starting points from day-to-day server work, not lab benchmarks. If you are asking how much RAM a VPS needs for WordPress, the honest answer is that it depends on where your memory actually goes, so let us look at that before you pick a plan.
Where the RAM goes on a WordPress VPS
WordPress itself is small. The memory bill comes from everything running around it. On a typical unmanaged VPS you have four or five things competing for RAM:
- PHP-FPM workers, the biggest consumer on most sites: every uncached page view gets handled by a PHP worker, and each worker holds WordPress, your theme, and every active plugin in memory. A worker with a light theme might use 30–40 MB; one loaded with a page builder and a dozen plugins often uses 60–100 MB.
- MySQL / MariaDB, the second biggest: the InnoDB buffer pool caches database pages in memory, and on a tuned small server this is usually the single largest fixed allocation, often 256–512 MB.
- The web server: Nginx uses very little memory. Apache with the prefork MPM uses noticeably more, which is one reason Nginx is the common pick for small VPS plans.
- Object cache (Redis or Memcached): Stores query results and objects in RAM so PHP does not hit the database as often. It costs memory but saves more than it spends, because it keeps PHP workers from piling up.
- The OS and everything else: The Linux kernel, SSH, cron, backups, monitoring agents, and your control panel if you use one. Budget 200–400 MB for this on a minimal server.
Once you see the stack this way, the sizing question stops being a guess. You are not buying RAM for WordPress. You are buying it for your PHP workers, your database cache, and your headroom.
How much RAM per type of site
These ranges assume a reasonably tuned stack (page caching on, PHP 8.x, MariaDB) on a modern Linux VPS. If your stack is untuned, read everything one row higher.
| Site type | Minimum | Comfortable |
|---|---|---|
| Single blog or brochure site, low traffic | 1 GB | 2 GB |
| Small business site, portfolio, a few plugins | 2 GB | 2–4 GB |
| WooCommerce starter store (real orders) | 2 GB | 4 GB |
| Busy store, large catalog, page builder site with traffic | 4 GB | 8 GB |
| WordPress multisite or several client sites on one VPS | 8 GB | 8–16 GB |
A note on WooCommerce: cart, checkout, and account pages skip the page cache, so a store does real PHP work on every order. That is why a store with the same visitor count as a blog needs more RAM.
How to measure what your site actually uses
Do not size from a table alone. Check your own server. Two commands tell you most of what you need:
free -h
htopfree -h shows total, used, and available memory. Available is the number that matters, because Linux uses spare RAM for disk cache and hands it back when programs need it. High “used” with high “available” is healthy. Low “available” plus swap in use is not.
In htop, press M to sort by memory and look at which processes sit at the top. If you see a crowd of php-fpm: pool www processes each eating 60–80 MB, your workers are the memory story. If mysqld dominates, the database cache is the story.
Watch over a few days, not five minutes. Memory pressure shows up during traffic peaks, backup windows, and cron runs. If you only look at 2 AM, you will miss it.
Signs you are running out of memory
Memory shortage has a recognizable pattern on a WordPress VPS:
- 502 / 504 errors at peak times: PHP-FPM cannot spawn or keep enough workers, so Nginx gives up waiting.
- “Error establishing a database connection”: MySQL got killed and WordPress cannot reach it. Check the logs before assuming the database is broken.
- The OOM killer in your logs: When the kernel runs out of memory, it kills the hungriest process. Confirm with:
dmesg | grep -i "killed process"If you see
mysqldorphp-fpmin that output, you have your answer. - Swap in constant use: A little swap during a spike is fine. Swap that stays in use during normal traffic means the server is living beyond its means.
- High load average with idle CPU: Processes waiting on a system starved of memory push the load average up even when the CPU has nothing to do.
Swap is a safety net, not a plan
Swap space lets the kernel move idle memory pages to disk when RAM fills up. It keeps the server alive during a spike instead of letting the OOM killer start shooting processes. That is worth having, and a 1–2 GB swap file is cheap insurance on a small VPS.
But swap is hundreds of times slower than RAM. A server that leans on swap during normal traffic will feel sluggish no matter what else you tune. Treat steady swap usage as a signal to fix the real problem: fewer workers, better caching, or a bigger plan.
Free up RAM before you buy more
Upgrading the plan is the last step, not the first. These moves often recover more memory than an upgrade would add:
- Turn on page caching. A cached page is served by Nginx without touching PHP or MySQL at all. For a blog, this alone can cut PHP memory use by 80% or more.
- Add an object cache (Redis). It costs 64–256 MB of RAM and pays for itself by keeping PHP workers from queueing on slow database queries.
- Right-size your PHP workers.
pm.max_childrenshould match your RAM, not the default. A rough formula:(total RAM − memory for MySQL and OS) ÷ memory per PHP worker. On a 2 GB VPS with a 512 MB InnoDB buffer pool and ~300 MB for the OS, you have about 1.2 GB left for PHP. At ~60 MB per worker, that is 20 workers, not the 50 some stacks ship with. - Size the InnoDB buffer pool sanely. On a small single-site VPS, 256–512 MB is usually plenty. A 2 GB buffer pool on a 2 GB server is a classic self-inflicted OOM.
- Cut the plugins you do not use. Every active plugin loads into every PHP worker. Audit the list once a quarter.
- Do not run a heavy control panel on 1 GB. Some panels want 1–2 GB just for themselves. On a tiny VPS, the command line plus a lightweight panel (or none) leaves far more room for the site.
WP_MEMORY_LIMIT is not server RAM
This confuses a lot of people, so it is worth one paragraph. The WP_MEMORY_LIMIT setting in wp-config.php caps how much memory one PHP request may use (WordPress defaults to 40 MB, WooCommerce asks for 256 MB). It is a per-request ceiling, not your server’s total memory. Raising it does not give your VPS more RAM, and on a 1 GB server, setting it very high while running many workers is a quick route to an OOM kill. Keep it modest (128–256 MB) and fix worker count and caching instead.
When it is actually time to upgrade
Upgrade the plan when the tuning is done and the numbers still say you are short:
- Available memory drops below ~10% during normal traffic, with page caching already on.
- Swap is in steady use, not just during spikes.
- You see OOM kills in
dmesgmore than once. - You had to set
pm.max_childrenso low that traffic queues during peaks. - You are adding a second site, a store, or a staging copy to the same VPS.
Most VPS providers let you resize without migrating, so there is little penalty in starting at 2 GB and moving up when the measurements say so. The expensive mistake is the other direction: paying for 8 GB to cover a caching problem that a free plugin would fix.
FAQ
Can WordPress run on a 512 MB VPS?
Technically yes, but it is not worth it for a production site. The OS, MySQL, and PHP-FPM barely fit, leaving no room for traffic spikes or updates. Start at 1 GB.
Does more RAM make WordPress faster?
Only up to the point where memory stops being the bottleneck. Going from starved to comfortable is a big jump. Going from comfortable to oversized changes nothing except the invoice.
What matters more for WordPress, RAM or CPU?
For most small sites, RAM, because running out of it crashes things. CPU becomes the limit on busy dynamic sites (stores, membership sites) where many PHP requests run at once. If you are unsure, fix memory first, then watch CPU during peaks.
How much RAM do I need to host multiple WordPress sites on one VPS?
Add roughly 512 MB–1 GB per extra low-traffic site on top of your base, and give each site its own PHP pool so one site’s traffic spike does not starve the others.