How much RAM does my website need?
By CloudCostly editorial team Published July 3, 2026 Updated July 12, 2026
Memory is usually the resource that runs out first, which makes it the number to get right when choosing hosting. Too little and your site slows or crashes under load; too much and you pay for headroom you never touch. This guide gives you a simple, practical way to size RAM by workload.
Why RAM matters most
Web servers, PHP processes, databases and caches all live in memory. When there is enough, requests are served quickly from RAM. When there is not, the server swaps to disk, which is dramatically slower, and under real pressure the operating system can start killing processes. Because memory is the usual bottleneck, sizing it correctly matters more than almost any other spec.
A quick guide by workload
| Workload | Recommended RAM |
|---|---|
| Personal blog, small static-plus-API site, Discord bot | 1 GB |
| Standard WordPress site with caching, small app | 2 GB |
| Growing WordPress or WooCommerce, typical Node or Django app | 4 GB |
| Busy store, database-heavy app, Minecraft server | 8 GB |
| Magento, GitLab with CI, several apps on one box | 16 GB and up |
Blogs and content sites
A personal blog is happy on 1 to 2 GB, especially with page caching that serves most visitors without touching PHP or the database. Content sites scale gently with traffic, so you can start small and size up only when real usage demands it.
WordPress and WooCommerce
A standard WordPress site fits comfortably in 2 GB with caching. Add WooCommerce and the picture changes: carts and checkouts cannot be fully cached, the database works harder, and 8 GB or more becomes sensible for a busy store. Our best hosting for WooCommerce page has specific recommendations.
Apps and frameworks
Node, Laravel, Django and similar apps typically sit in the 1 to 4 GB range depending on concurrency and what they cache in memory. Background workers, queues and in-memory stores like Redis add to the requirement, so account for the whole stack, not just the web process.
Game servers and databases
A Minecraft server is mostly bound by RAM because the Java runtime holds the world and players in memory, so 4 to 8 GB is a good starting point. Databases love memory too, using it to cache the working set, so a busy database benefits from 8 GB or more and fast NVMe storage underneath.
The one-step-up rule
When you are between sizes, choose the larger one. The cost of the next tier is usually small compared with the pain of running out of memory on launch day or during a traffic spike. Headroom is cheap insurance against a slow or crashing site.
How to match RAM to a real plan
Once you know your target, our sizing checker shows which real plans meet that amount of RAM within your budget, and the cost calculator finds the cheapest option that provides it. Both work from real, current plan data.
How to measure your real memory use
Guessing is fine to start, but measuring is better once you are live. On a Linux server the free and top commands show current memory use, while a lightweight monitoring tool records it over time so you can see peaks under real traffic rather than a single snapshot. What you care about is the high-water mark during your busiest period, plus a margin. If you regularly sit near capacity when traffic arrives, that is your signal to size up. If you are using a fraction of your RAM even at peak, you are paying for headroom you could trim.
Swap and out-of-memory errors explained
When a server runs low on RAM it starts using swap, a slice of disk pretended to be memory. Swap prevents an immediate crash, but disk is far slower than RAM, so the site drags. If pressure continues, the Linux out-of-memory killer terminates a process to free memory, often the database or web server, which takes your site down. Swap is a safety net, not a substitute for enough RAM. If you see heavy swapping or out-of-memory events in your logs, do not tune around them, add memory.
RAM versus caching: spend where it counts
More RAM is not the only way to handle traffic. A good caching layer often does more for less: page caching serves visitors without spinning up PHP or hitting the database, dramatically reducing memory pressure per request. In practice the best value comes from pairing a sensible amount of RAM with strong caching, rather than throwing memory at an uncached site. Before jumping two tiers up, check whether adding a cache would let a smaller plan cope. Our WordPress hosting guide covers the caching layers that matter.
How the database uses memory
For dynamic sites, the database is often the hungriest part of the stack. MySQL, MariaDB and PostgreSQL all use memory to cache the working set of your data, so that frequent queries are answered from RAM rather than disk. When there is enough memory, the database feels instant; when there is not, it falls back to disk and everything slows. This is why a database-heavy site benefits from more RAM than a simple content site of the same traffic. If your app runs its own database on the same server, size for the web processes and the database together, not just one of them.
Concurrency changes everything
Two sites with the same content can need very different amounts of memory depending on how many visitors arrive at once. Each simultaneous dynamic request consumes memory for the duration it runs, so a burst of traffic multiplies the requirement. Caching helps enormously here by serving most visitors without spinning up a new process, but for genuinely dynamic, uncacheable requests, concurrency is the driver. When you estimate RAM, think about your busiest minute, not your average, because that peak is when running out of memory actually hurts.
RAM for containers and multiple apps
If you run several applications on one server, or use containers, memory planning changes a little. Each container or app carries its own footprint, and they all draw from the same pool, so the server needs enough RAM for the sum plus the operating system and a margin. Running a database, a web app and a cache together on a small box is a common cause of memory pressure. Either size up so everything fits comfortably, or split heavy components onto their own machines. The best hosting for Docker page has guidance on sizing container hosts specifically.
Right-sizing without waste
Sizing is a balance: too little RAM risks a slow or crashing site, too much wastes money on headroom you never touch. The sensible approach is to start from the workload guide above, add a margin for spikes, then measure real usage once you are live and adjust. If you consistently use a small fraction of your memory, you can drop a tier and save. If you regularly brush the ceiling, move up one. Our cost calculator makes it easy to see what each amount of RAM costs across providers, so adjusting is a quick decision rather than a guess.
RAM and vCPU work together
Memory rarely acts alone, and it helps to think of RAM and vCPU as a pair. A site can have plenty of memory yet still feel slow if it is starved of CPU during traffic spikes, and vice versa. Balanced plans pair a sensible amount of each, which is why most VPS tiers scale RAM and vCPU together rather than letting one race ahead. If you find yourself with spare memory but a pegged CPU, or the reverse, that imbalance is a signal to choose a differently proportioned plan rather than simply adding more of the resource you already have plenty of. Reading the whole spec, not just the RAM figure, leads to a better-matched server.
Cloud memory versus dedicated memory
Not all advertised RAM behaves identically. On shared and burstable plans, some memory may be shared or subject to fair-use limits, so a plan that lists a generous figure can perform less consistently than a dedicated-resource plan with the same number. Dedicated-CPU and standard VPS plans give you memory that is genuinely yours at all times, which matters for databases and steady workloads that dislike surprises. When you compare plans, note whether the resources are dedicated or shared, because two plans with identical headline RAM can feel very different under sustained load. Our plans page shows the plan type so you can compare like with like.
Conclusion
Sizing RAM is mostly common sense once you know the rough figures: 1 to 2 GB for a blog, 4 GB for a growing site or app, 8 GB and up for stores and databases. When unsure, size up one tier. Use the sizing checker to turn your target into a shortlist of real plans.
Frequently asked questions
How much RAM does a WordPress site need?
A personal WordPress blog is comfortable on 1 to 2 GB. A business site wants 4 GB, and a WooCommerce store 8 GB or more with a fast database and object caching.
Is more RAM always better?
Only up to a point. RAM is usually the first resource to run out, so having enough is important, but paying for memory you never use is waste. Size for your workload plus headroom, not for the maximum.
What happens if my site runs out of RAM?
The server starts swapping to disk, which is far slower, and under heavy pressure processes can be killed. The result is a slow or crashing site, usually at the worst possible moment under load.
How do I know if I need more RAM?
Watch memory usage under real traffic. If you are regularly near capacity or swapping, size up one tier. Our sizing checker helps you match plans to a target amount of RAM.