How much RAM do you really need for servers and VPS in 2025?

Sizing RAM is workload arithmetic, not a benchmark. Overspend and you pay for idle capacity. Undershoot and your processes get killed, your database serves from disk instead of memory, or your containers get throttled. This guide gives concrete RAM ranges for the workloads we see most often (web hosting, databases, virtualisation, containers, AI inference, and game servers), plus the rules to use when sizing for something that is not on the list.

What RAM does in a server

RAM holds everything the server is actively working on. Process memory for web servers, database engines, and background daemons. OS-level page cache and disk I/O buffers. Runtime memory for applications and containers. And the chunks of memory handed to virtual machines or container workloads.

What makes RAM sizing different from CPU sizing is the failure mode. Run out of CPU and processes slow down. Run out of RAM and the kernel either swaps (slow) or the OOM killer picks a victim and ends it. The first feels bad. The second loses data. Provisioning RAM with margin is not a nice-to-have, it is what stops the bottom falling out under load.

RAM by workload

Web and application servers

• Lightweight LAMP or LEMP stack: 1 to 2 GB
• WordPress or CMS with caching (e.g. Redis): 2 to 4 GB
• E-commerce (Magento, WooCommerce): 4 to 8 GB
• Node.js, Django, or Rails apps: 2 to 6 GB

Caching layers like Redis or Varnish want RAM of their own on top of the application baseline. PHP-FPM workers, database connections, and reverse proxies all consume memory concurrently, so the figure that matters is peak parallelism, not idle footprint.

Database servers (SQL and NoSQL)

• MySQL or PostgreSQL (small): 4 to 8 GB
• MySQL or PostgreSQL (large or high-traffic): 16 to 64 GB
• MongoDB or Redis (in-memory focus): 32 to 128 GB or more
• Elasticsearch or OpenSearch nodes: 32 to 128 GB per node

The goal is keeping the working set, the indexes and the frequently accessed rows, in RAM. Once any of that spills to disk, latency multiplies by orders of magnitude, no matter how fast the SSD is.

Virtualisation hosts (Proxmox, VMware, Hyper-V)

• Lightweight Linux VMs: 2 to 4 GB per VM
• Windows VMs: 8 to 12 GB per VM
• Hosting panels (cPanel, Plesk, DirectAdmin): 4 to 8 GB per instance
• KVM or LXC container hosts: 32 to 128 GB or more

Always reserve 4 to 8 GB for the host OS itself, on top of guest allocations. Containers use less RAM per workload than full VMs but scale differently, so plan for density and burst headroom rather than per-container size. If the host uses ZFS, also account for the ARC, which will silently take up to half of system RAM by default and compete with guest allocations (our ZFS ARC tuning guide covers the right caps for hypervisor workloads).

Containers and microservices (Docker, Kubernetes)

• Simple Docker stacks (web, app, DB): 8 to 16 GB
• Docker Swarm or K3s edge nodes: 16 to 32 GB
• Kubernetes worker nodes: 32 to 128 GB
• CI/CD runners and build agents (GitLab, Jenkins): 8 to 32 GB per runner

Watch for memory leaks on long-running containers. JVM-based workloads like Kafka and Elasticsearch need higher baselines because the heap will settle wherever you let it, which is often higher than you expected.

AI and ML inference

• Small models (quantised BERT, Llama 7B): 16 to 32 GB
• Medium models (13B to 30B, quantised): 64 to 128 GB
• Large models (40B+ or non-quantised mid-range): 128 to 512 GB or more
• GPU-backed inference (Stable Diffusion, Whisper): 32 to 128 GB depending on offload

Quantisation shifts memory pressure from GPU to CPU RAM, so the system spec changes meaningfully depending on whether you serve fp16 on GPU or 4-bit on CPU. Batch size and prompt length push the numbers up too. Our guide to AI inference hosting goes deeper on matching hardware to model size.

Game servers

• Minecraft (vanilla): 2 to 4 GB
• Minecraft (modded): 6 to 16 GB
• Rust, ARK, or 7 Days to Die: 8 to 16 GB
• Multi-instance hosting nodes: 32 to 64 GB

Specialised workloads

• Video transcoding (FFmpeg, Plex): 16 to 64 GB
• Backup or snapshot servers: 8 to 16 GB, more if running deduplication engines
• Firewall or IDS (pfSense, Suricata): 2 to 8 GB, more for NetFlow or full packet logging

Don't rely on swap memory

Swap is 10 to 100 times slower than RAM. It exists as a safety net so the kernel has somewhere to go when memory pressure spikes, not as a way to extend usable memory. If a server is hitting swap under normal load, it is underprovisioned, full stop. How Linux swap, the OOM killer, and cgroups interact covers the failure modes in detail.

How to size RAM accurately

1. Measure peak, not average. Use htop, free -m, vmstat 1, or your Kubernetes metrics to find peak usage across a full traffic cycle. Daily peaks, weekly batches, and monthly billing runs all matter.
2. Add headroom for growth. 20% to 50% for app scaling. For databases, scale memory with dataset size, not request rate. For multi-tenant platforms, calculate per-client footprint and multiply.
3. Plan around the failure mode you can tolerate. A read replica running short on RAM degrades. A database primary running short corrupts queries and can take applications down with it. Spend the RAM where the blast radius is biggest.

RAM is the spec where running short hurts more than running over. Adding memory will not make a CPU-bound application faster, but running too lean destroys stability. Size from real monitoring and your tested peaks, then leave room.

FDC offers Dedicated Servers and VPS with high-RAM configurations and unmetered bandwidth across multiple regions.