"Just get 32GB to be safe" is the RAM-sizing advice equivalent of guessing — sometimes it is wildly overkill, sometimes it is dangerously insufficient. RAM needs scale with a specific set of variables: concurrent connections, per-process memory footprint, database buffer pool size, and headroom for OS caching. This guide breaks sizing down by workload with real numbers, so you can size a server based on your actual traffic and data volume rather than a round number that feels safe.
The RAM Sizing Framework
Before picking a number, work out four things: (1) baseline OS and system-service memory (typically 1-2GB on a modern Linux distro), (2) per-connection or per-worker memory for your application, (3) your database's buffer pool / cache size needs, and (4) headroom for OS disk caching, which meaningfully improves performance by keeping hot data in RAM rather than reading from disk repeatedly. Skipping the headroom step is the most common sizing mistake — a server sized exactly to your peak process memory with zero spare capacity will swap under any unexpected load spike.
RAM Sizing by Workload
WordPress / Small-to-Medium Web Applications
| Site Size | Concurrent Users | Recommended RAM | Notes |
|---|---|---|---|
| Small brochure site | Under 50 | 4-8 GB | PHP-FPM with a modest worker pool, small MySQL buffer pool |
| Medium content/blog site | 50-500 | 8-16 GB | Add object caching (Redis/Memcached) and a larger InnoDB buffer pool |
| High-traffic e-commerce | 500+ | 16-32 GB | Full-page caching becomes essential at this scale, not optional |
PHP-FPM workers typically consume 30-80MB each depending on your application's complexity and loaded plugins — multiply your expected concurrent PHP requests by that figure and add 25% headroom to get a realistic floor.
Databases (MySQL/PostgreSQL)
The single biggest lever is the buffer pool (MySQL's innodb_buffer_pool_size) or shared buffers (PostgreSQL's shared_buffers) — as a rule of thumb, size this to 60-70% of total server RAM on a dedicated database server, since the goal is to keep your working data set cached in memory rather than hitting disk on every query.
| Database Size (working set) | Recommended RAM | Buffer Pool Setting |
|---|---|---|
| Under 5 GB | 8-16 GB | ~5-10 GB |
| 5-50 GB | 32-64 GB | ~20-45 GB |
| 50+ GB, high concurrency | 128 GB+ | ~90+ GB |
Game Servers
Game server RAM needs depend heavily on player count and world/save complexity — a small Minecraft survival server with 10 players runs comfortably in 4-8GB, while a modded 50-player ARK: Survival Ascended cluster can realistically need 16-32GB across its map instances. Always check the specific title's per-player memory scaling since it varies enormously between engines (Source-engine shooters are far lighter per-player than a modded survival-crafting title with a large persistent world).
Virtualization Hosts (Running VMs on a Dedicated Server)
Budget the sum of all guest VM allocations, plus 10-20% overhead for the hypervisor itself (KVM, Proxmox, VMware), plus avoid overcommitting RAM across guests unless your workloads are genuinely bursty and non-overlapping in peak usage — memory overcommit that looks fine on paper can cause simultaneous swapping across every guest during a shared traffic spike.
Signs You Are Undersized on RAM
- Persistent or growing swap usage (check with
free -h— swap should be near-zero on a healthy production server) - OOM killer entries in
dmesgor/var/log/messages, indicating the kernel had to forcibly kill a process for memory - Database query times that degrade under load, often indicating a buffer pool too small to keep the working set cached
- Rising response times that correlate with traffic spikes rather than CPU exhaustion
Signs You Are Oversized (Paying for Unused Capacity)
free -hconsistently shows the large majority of RAM as "available" even at peak traffic hours- No swap usage ever, even under simulated stress testing at 2-3x normal traffic
- Database buffer pool set far larger than your actual working data set (diminishing returns beyond the point where the whole working set already fits in cache)
RAM vs Other Upgrades: Getting the Priority Right
More RAM cannot compensate for a CPU-bound bottleneck (heavy computation, video transcoding, high concurrent request processing with CPU-intensive per-request work), and it cannot compensate for slow storage on workloads that are genuinely disk-I/O bound rather than cache-miss bound. Diagnose with top/htop (CPU), free -h and swap activity (RAM), and iostat (disk I/O wait) before assuming RAM is the correct upgrade — see our monitoring guide for setting these checks up properly rather than diagnosing manually under pressure.
ECC vs Non-ECC RAM
ECC (Error-Correcting Code) RAM detects and corrects single-bit memory errors automatically, which matters considerably more on servers than desktops given 24/7 operation and the cost of silent data corruption in a database. Nearly all reputable dedicated server providers use ECC RAM by default in server-grade hardware — confirm this explicitly if you are ever quoted a suspiciously cheap plan, since non-ECC RAM in a "server" is a red flag worth investigating.
Buyer's Checklist
- Size RAM to your actual working data set and concurrency, not a round number that "feels safe"
- Confirm ECC RAM is included, not a downgraded non-ECC configuration
- Check whether the provider allows RAM upgrades without a full server rebuild/migration
- Factor in headroom for OS caching and traffic spikes, not just steady-state peak usage
- For databases specifically, size around your buffer pool needs first, everything else second
Frequently Asked Questions
How much RAM does a small business website need?
4-8GB is typically sufficient for a small-to-medium WordPress or similar CMS site with moderate traffic and basic caching in place.
Does more RAM always mean better performance?
Only up to the point where your actual working data set and concurrent connections are fully served from memory — beyond that, additional RAM sits idle while a CPU or disk I/O bottleneck goes unaddressed.
How do I know if my server needs a RAM upgrade?
Persistent swap usage, OOM killer log entries, or database performance that degrades specifically under concurrent load are the clearest practical signals.
Is ECC RAM worth the extra cost?
Yes, for any production server — the cost difference is small relative to the risk of silent memory corruption affecting a database or application over months of 24/7 uptime.
Should I size RAM based on peak traffic or average traffic?
Size based on peak (plus headroom for unexpected spikes) — a server that performs well on average but swaps or OOM-kills during your busiest traffic hour has effectively failed at its job during the moments that matter most.
Can I add more RAM to a dedicated server later?
Often yes, though it may require scheduled downtime and is subject to your motherboard's maximum supported capacity and available DIMM slots — confirm upgrade paths with your provider before you actually need one urgently.
Our team can help size RAM correctly for your specific workload rather than guessing at a round number. View dedicated server configurations or contact us for a sizing consultation.