How much RAM does a server need? Planning capacity, ECC and headroom

Understand the bottleneck first

RAM holds data and program state that processors need to access quickly. If usable memory runs short, the system may swap memory pages, shrink caches or terminate processes. The result can be a slow business management system even when the CPU appears barely busy. Conversely, an extra 64 GB will not accelerate an application waiting for an external interface or a single fully occupied processor core.

High memory usage alone is no reason to buy more: operating systems put spare RAM to good use as cache. What matters is available memory, recurring memory pressure, swapping activity and the application's response time measured at the same time. Linux provides Pressure Stall Information to measure how long tasks wait because CPU, memory or I/O resources are scarce. This helps distinguish a real bottleneck from productive cache use. Linux kernel: Pressure Stall Information ↗

Record at least one representative business cycle: normal working days, backups, reports and month-end processing. A quiet Tuesday morning does not represent an overnight data import. Note the number of users, data volume and software version alongside the measurements. This makes it possible to explain changed requirements after an upgrade.

Example: RAM for a small virtualisation host

The following plan is a hypothetical example for a business running several internal services. The values are assumed memory budgets needed simultaneously. They are not minimum requirements for particular products. The starting point is 64 GB of physical memory and whether this leaves enough room for daily operation, maintenance and growth.

Using a self-selected planning allowance of 25 per cent gives 50 × 1.25 = 62.5 GB. A 64 GB configuration could be a first expansion stage here, but it sits close to this planning limit. The 14 GB of headroom is 28 per cent of the initial requirement. If the database budget alone grows by 12 GB, the original reserve is practically exhausted. Expansion or moving a workload elsewhere would then be necessary.

Databases need their own memory budget

A database's size on SSD does not directly determine its RAM requirement. A large database may work with a small, frequently used dataset. A smaller database may suddenly need substantial memory for many concurrent sorts. We therefore consider active data, indexes, concurrent queries and regular maintenance together.

For a dedicated database server with at least 1 GB of RAM, PostgreSQL gives around 25 per cent as a starting value for shared_buffers. This is a configuration starting point, not a recommendation to size the whole server around this proportion alone. work_mem can be allocated per sort or hash operation; multiple operations and sessions can multiply the total requirement. Other services and the operating system cache need additional space. PostgreSQL: memory parameters and resource consumption ↗

Check queries, indexes and unnecessary concurrency first. An export running alongside an import and a backup can cause much lower peaks if these jobs are scheduled apart. More RAM makes sense when measurements show a growing active dataset. For a faulty application with unbounded memory growth, it may merely delay failure.

ECC is a property of the whole system

ECC memory can detect and correct certain memory errors. Which errors are covered and how the system responds depend on the platform. Intel notes that ECC requires both processor and chipset support. Before ordering, the approvals for the specific motherboard, firmware and memory modules must also align. Intel: requirements for ECC support ↗

DDR5 with on-die ECC does not automatically make a server with system-wide ECC protection. This internal correction covers errors within the DRAM chip. Additional system-level protection requires suitable ECC modules and platform support. ECC UDIMMs and RDIMMs are not freely interchangeable either. Buy according to the system's compatibility list, not just capacity and clock speed. Kingston: DDR5 and on-die ECC ↗

Plan modules, memory channels and expansion together

The same total capacity can provide different memory bandwidth with different module populations. The CPU's memory channels and the manufacturer's recommended population matter. Plenty of empty slots may be attractive for later, but a heavily unbalanced configuration today can waste bandwidth. Additional modules may also require a different permitted speed. Follow the manual for the chosen platform.

• Check the maximum capacity and supported module sizes for both CPU and motherboard.
• Record the DIMM type, module count per channel and permitted mixed configurations in writing.
• Plan the initial population and a specific second expansion step with a parts list.
• Check approved modules and their availability before choosing a tight initial configuration.
• After installation, check recognised capacity, ECC operation and hardware messages.

Consider overcommitment and failure reserves separately

Virtual machines can nominally receive more memory than is physically available. Whether this is sustainable in a specific environment depends on actual concurrency, the hypervisor and memory reclamation mechanisms. For latency-sensitive databases, the calculation should not depend on another guest happening to need little RAM. A host that looks comfortable during normal operation can come under pressure while several guests restart.

With two hosts and automatic failover, the total number of GB is also misleading. If essential VMs together need 80 GB, they must fit within the remaining capacity after a host failure, including the host's own requirement. Two hosts with 64 GB each do not meet this goal merely because 128 GB is available in everyday operation. Deliberately shutting down less important test systems can be a documented alternative.

When the plan is reliable

Define success before buying: for example, a monthly report within an agreed time window, no memory-related process failures and enough headroom during concurrent backups. Then test that exact workflow with realistic data suitable for the test. Repeat the measurements after significant software or data changes.

The result should fit on one page: load assumptions, measured peaks, memory budget, failure requirements and the expansion limit. A second person can then follow the decision. When the next quote arrives, it becomes possible to compare whether a more expensive system solves a specific problem or merely sells extra capacity without operational value.