How much RAM does your VPS actually need? Numbers by workload

bigdomain host — Thu, 29 Oct 2026 16:38:27 +0000

Disclosure: I'm Parth, I run Bigdomainhost, an Indian hosting company, and the price column below is our own plan list. The RAM numbers apply to any host.

Almost every VPS gets bought one size too big or one size too small. Too small looks like WordPress, MySQL and a page builder squeezed into 2 GB, throwing "Error establishing a database connection" every few days. Too big looks like a 32 GB box running a 3 GB workload.

Both are fixable with some simple arithmetic. This post is that arithmetic.

Start with what uses the memory

On a normal LAMP or LEMP server, the RAM goes to a handful of things. Typical ranges:

Component	Typical usage
Minimal Ubuntu / AlmaLinux, no desktop	200-400 MB
MySQL / MariaDB	500 MB to 2 GB
PHP-FPM	40-120 MB per worker
Nginx	50-100 MB
Apache with mod_php	a lot more than Nginx
LiteSpeed	somewhere between the two
Redis	whatever you cap it at, usually 256 MB to 2 GB
cPanel	about 1 GB before you host a single site

Two lines in that table do most of the damage.

The first is PHP-FPM. People look at "40-120 MB" and think it's small. It's per worker. A WordPress site with Elementor or similar sits at the top of that range, so ten workers at 100 MB is a full gigabyte on its own.

The second is the MySQL InnoDB buffer pool. Ideally it holds your entire working data set in memory. If it can't, every query that misses the pool goes to disk and your "slow site" problem is actually a RAM problem wearing a disguise.

Add up the components you actually run, then put 25-30% on top. A server that is full at idle has nothing left for your busiest hour of the day.

Why I size RAM generously and CPU tightly

This is the one opinion I'd defend hardest in this whole post.

When a server runs short of CPU, it gets slow. Requests queue, pages take longer, but they come back.

When it runs short of RAM, it breaks. Linux first starts swapping to disk, which is orders of magnitude slower than memory. When swap is used up too, the kernel's out-of-memory killer picks the largest process and kills it. On a web server the largest process is almost always MySQL. So the visible symptom isn't "slow", it's "Error establishing a database connection" until someone or something restarts mysqld.

CPU pressure degrades. RAM pressure breaks. So if the budget forces a trade-off, take the extra RAM.

Rules of thumb that have held up for us

WordPress, cached: roughly 1 GB per busy site, including its share of MySQL.
WooCommerce: double that. Cart, checkout and My Account can't be page-cached, so every one of those requests hits PHP and MySQL.
Minecraft: about 1 GB per ten vanilla players, plus whatever the modpack says it needs, rounded up.
Tally on Cloud: Windows Server wants about 4 GB before Tally even starts. 8 GB is comfortable for one or two concurrent users.
Node and Python APIs: measure. They vary more than anything else here, and any number I give you will be wrong for your app.

The cheat sheet

Here's how that maps to plan sizes. Prices are our own plans in rupees, excluding 18% GST, because that's what I know. The RAM column is the part that transfers to any host.

Workload	RAM	Our plan (per month)
Static site, small API, dev box	2 GB	₹674
1-3 WordPress sites, cached	4 GB	₹674
Production WordPress + MySQL	8 GB	₹1,348
WooCommerce store	8-16 GB	₹1,348-₹2,696
10-20 sites behind cPanel	16 GB	₹2,696
Redis or Elasticsearch node	16 GB+	₹2,696
Tally on Cloud, 1-2 users	8 GB	₹1,899
Modded Minecraft, 20-40 players	16 GB	₹2,696
CI runners, build servers	16-32 GB	₹2,696-₹5,017

Measure what you're using right now

If you already have a server, don't guess. Three commands tell you most of what you need:

# free memory, human readable
free -h

# the ten biggest processes by memory
ps aux --sort=-%mem | head -11

# is it swapping? (5 samples, 1 second apart)
vmstat 1 5

Two things to read correctly.

In free -h, look at the available column, not free. Linux uses spare memory as disk cache and gives it back on demand. A low "free" number is normal and healthy. People panic over it all the time and it means nothing.

In vmstat, watch the si and so columns (swap in, swap out). If they're non-zero across samples, the box is actively swapping. That's your signal to add memory, not to tune something.

If you want to see how much each PHP-FPM worker is actually taking on your site, rather than trusting my 40-120 MB range:

ps -o rss,cmd -C php-fpm --sort=-rss | head

RSS is in KB. Multiply your typical worker size by pm.max_children in your pool config and you'll know whether your FPM settings can even fit in the RAM you have. (The process name may be php-fpm8.2 or similar depending on the distro, so adjust the -C value.)

Should you add swap?

Yes, 1-2 GB of it. Treat it as an emergency buffer that turns a hard crash into a slow patch. It is not a substitute for RAM. If you're swapping routinely, buy more memory.

On a box without swap, the usual setup is:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
grep -q '^/swapfile ' /etc/fstab || echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

The grep guard stops you adding a duplicate fstab line if you run it twice. Then free -h again to confirm the Swap row shows 2.0Gi. (On some filesystems fallocate swap files fail swapon; if that happens, create the file with dd instead.)

Is 1 GB ever enough?

For a static site, a small API or a personal project, yes. For WordPress with MySQL on the same machine, it's tight enough that one traffic spike will wake up the OOM killer. If the site matters to anyone, start at 2 GB. For a production WordPress site with the database on the same box, 4 GB is the sensible starting point, and 8 GB once WooCommerce or a dozen client sites are involved.

When CPU does matter more

There are workloads where I'd reverse my advice: video encoding, heavy cron jobs, and game servers. For game servers, single-core speed beats core count. A Minecraft server's main loop mostly runs on one thread, so extra cores don't help it the way they help a pool of PHP workers.

Don't over-buy either

A 32 GB server running 3 GB of workload is money spent on nothing. Our plans resize in place: vCPU, RAM and disk grow with a single reboot and nothing gets reinstalled. If your host can do the same, the right move is to start one size down and move up when free -h and vmstat tell you to, not when a sales page does.

If your host can't resize in place and a move means a full rebuild, that changes the maths. Then I'd buy one size up and accept some waste, because a migration under pressure costs more than the extra RAM.

The full VPS ladder we sell, with Mumbai (BOM-1) and Delhi NCR (DEL-1) locations, is on the KVM VPS page. If you're still deciding whether you need a VPS at all, we also wrote up VPS vs shared hosting, and the original version of this guide is here.

Posted by Parth from Bigdomainhost. The original version of this guide is on our site.

DEV Community: bigdomain host