Memory is the dimension a server most often runs out of first - and the one most often guessed at. How much RAM you need is a methodology question, not a number you can copy from someone else's build, because it depends on what the workload holds in memory, how much the operating system caches, and how much headroom you keep. This is a memory-only look at right-sizing server RAM, separate from the mechanics of how you populate the DIMMs.
Memory is usually the first ceiling you hit
On most servers - and almost all virtualisation hosts - RAM, not CPU, is what runs out first. CPUs sit well below capacity while memory fills with running VMs, database working sets and cached data. Because adding memory to a running production server means downtime, getting the sizing right at purchase matters more than for almost any other component. Under-buy and you are RAM-bound within a year; over-buy and you have paid for capacity that sits idle.
So memory deserves its own sizing exercise rather than a round number. The method is to add up what the workload genuinely needs to hold in memory, account for what the OS and hypervisor consume, and then apply deliberate headroom - in that order.
Size from the workload's working set
Start with what the workload keeps resident. For a virtualisation host, that is the committed memory of all the VMs you intend to run, plus per-VM overhead. For a database, it is the hot working set you want cached in memory to keep queries fast - or, for an in-memory database, the whole dataset. For an application server, it is the runtime footprint of the application and its caches.
A useful framing is GB-per-VM or GB-per-core, sanity-checked against the actual workload. Typical mid-tier virtualisation lands around 16-24GB per VM; VDI and databases push far higher; lightweight roles need very little. Express the requirement per unit, multiply up, and you have a defensible baseline rather than a guess.
- •Virtualisation host: sum of VM committed memory + per-VM overhead
- •Database: hot working set to cache (or the whole dataset for in-memory)
- •Application server: runtime footprint + application caches
- •Lightweight roles (DC, file): modest fixed amount, do not over-buy
Account for overcommit and the page cache
Two effects complicate the simple sum. First, hypervisors can overcommit memory - presenting more virtual RAM than physically exists - using techniques like ballooning, page sharing and compression. Modest overcommit is safe for workloads that do not all peak together; aggressive overcommit risks swapping under load, which is far worse than buying enough RAM. Treat overcommit as a careful efficiency, not a substitute for capacity.
Second, operating systems use otherwise-free RAM as a page cache to speed up disk access. This is a feature, not waste - but it means a workload that benefits from caching effectively wants more memory than its bare minimum. File servers and read-heavy databases in particular reward extra RAM the OS can turn into cache, which is why 'just enough' often performs worse than a sensible margin above it.
Headroom, ECC and growth
Always size in headroom. A host running at 95% memory on day one has nothing left to absorb a failed node in a cluster, to handle growth, or to ride out a spike. A common, sensible target is to size so steady-state utilisation sits around 60-70%, leaving real margin. For clusters, also keep N+1 memory headroom so any single host can be evacuated and its VMs absorbed by the rest under that target.
On the hardware side, server RAM should be ECC - error-correcting memory that detects and corrects the bit errors that occur at scale - and it is standard on all the platforms worth buying. The question is rarely whether to use ECC, but how much capacity and how to populate it for full bandwidth. That population question - DIMM ranks, channels, 1 versus 2 DIMMs per channel - is its own topic; here, just be sure you have specified enough total capacity. Plan it with our server memory guidance.
Landing on the right capacity
The method in one line: size the working set, add OS and hypervisor overhead, treat overcommit as careful efficiency rather than free capacity, and size for 60-70% steady-state with N+1 headroom in clusters. That gives a capacity that is generous enough to perform and to grow into, without paying for idle terabytes. For a vSAN host specifically, factor in the storage stack's own memory appetite - see our VMware vSAN page - get the full build sized by our server configuration service, and choose the memory with our memory guidance.