For most development work in 2026, 32 GB of DDR5 is the practical floor, 64 GB is the comfortable default once containers, a local Kubernetes cluster, or a VM are part of the day, and 96 to 128 GB or more is for several VMs, large datasets, or local LLMs with CPU offload. Buy that capacity as two matched modules rather than four, and run it at the CPU's official speed or at a profile you have tested. Compare kits by latency in nanoseconds, not by CAS number, and choose real ECC only on a platform that supports and reports it end to end.
Size memory by workload
Memory pressure comes from things that run at the same time, so add up the peaks that overlap, not the averages.
Editors, browsers, and language servers
An IDE is rarely the problem by itself. The cost comes from language servers and indexers for every open project and from a browser full of documentation and the apps you are building. For this load alone, 32 GB leaves room for builds and for the file cache that makes repeated builds fast.
Containers and Kubernetes in Docker
On macOS and Windows, containers run in a Linux VM with a fixed ceiling. Docker Desktop on macOS defaults its memory limit to 50% of host memory, and on Windows the WSL 2 backend inherits the WSL memory setting, which also defaults to 50% of Windows memory (WSL configuration). On a 32 GB laptop that leaves about 16 GB for every container, kind node, and build. Parallel coding agents multiply the load, because each worktree may start its own dev server, test database, and build, as the agentic coding guide describes.
Databases and virtual machines
PostgreSQL's documentation suggests 25% of RAM for shared_buffers on a dedicated server, but a workstation is not one. Size database buffers to the working set you actually query. Virtual machines are simpler: unless the hypervisor uses ballooning or dynamic memory, a running guest keeps most of its configured RAM. Microsoft's minimum for Windows 11 is 4 GB, and a guest with an IDE inside needs much more. Two or three guests at once are a common reason to outgrow 64 GB.
Local LLMs with CPU offload
Weights take roughly parameters × bits per weight / 8 bytes, so a 70B model at about 4.5 bits per weight needs around 39 GB before the KV cache and runtime overhead. Layers that do not fit on the GPU live in system RAM and are read for every generated token. Capacity decides whether the model loads, and bandwidth caps how fast it generates. The local LLM hardware guide covers GPUs and quantization.
Measure your own peak before buying
The number that matters is the peak of your heaviest normal day. On Linux, log available memory and pressure every 30 seconds while you work:
#!/usr/bin/env bash
# Log memory headroom and pressure every 30 seconds (stop with Ctrl+C)
while true; do
{
printf '%s ' "$(date -Is)"
awk '/^(MemTotal|MemAvailable|SwapTotal|SwapFree):/ {printf "%s %d ", $1, $2/1024}' /proc/meminfo
awk '/^some/ {print "psi_some_" $2}' /proc/pressure/memory
} >> "$HOME/mem-headroom.log"
sleep 30
done
Then compute the peak as total memory minus the lowest MemAvailable. Because MemAvailable counts reclaimable cache as free, the result is what applications needed:
awk '{t=$3; a=$5; if (min == "" || a < min) min = a}
END {printf "peak used: %d MiB of %d MiB\n", t - min, t}' "$HOME/mem-headroom.log"
Pressure matters as much as the peak. some avg10 is the 10-second average share of time in which at least one task waited for memory. Sustained non-zero values, growing swap, or OOM kills in journalctl -k mean the machine is already short. Swap on a fast drive softens this but does not replace RAM, and the NVMe SSD buying guide covers the storage side.
For one heavy command, such as a full build, run it in its own cgroup and read memory.peak, the maximum usage recorded for the cgroup and its descendants, page cache included:
cat > peak-mem.sh <<'EOF'
#!/usr/bin/env bash
# Run a command and report the peak memory of its cgroup
"$@"
status=$?
cg="/sys/fs/cgroup$(cut -d: -f3 /proc/self/cgroup)"
echo "memory.peak: $(( $(cat "$cg/memory.peak") / 1048576 )) MiB" >&2
exit "$status"
EOF
chmod +x peak-mem.sh
systemd-run --user --scope --quiet ./peak-mem.sh make -j"$(nproc)"
Use docker stats --no-stream for containers and kind nodes, Activity Monitor's memory pressure graph on macOS, and committed memory in Task Manager on Windows. Add headroom, then round up to a capacity two modules can provide.
Channels and why two DIMMs usually beat four
Mainstream desktops such as AMD Ryzen 9000 on AM5 and Intel Core Ultra 200S have two DDR5 channels. Each DDR5 DIMM has two fully independent subchannels with 32 data bits each, so a dual-channel desktop moves 128 data bits per transfer. Peak theoretical bandwidth follows:
bandwidth (GB/s) = channels × 8 bytes × data rate (MT/s) / 1000
2 × 8 × 5600 / 1000 = 89.6 GB/s dual-channel DDR5-5600
2 × 8 × 6400 / 1000 = 102.4 GB/s dual-channel DDR5-6400
Four DIMMs on the same two channels add capacity, not bandwidth.
One DIMM per channel versus two
A fully populated four-slot board runs two DIMMs per channel, and every extra module loads the same signal lines. AMD's specification for the Ryzen 9 9950X lists DDR5-5600 for two modules and DDR5-3600 for four, single-rank or dual-rank (AMD Ryzen 9 9950X specifications). Intel's brief states that maximum speeds apply to one DIMM per channel and that additional loading may reduce them (Intel Core Ultra desktop Series 2 brief).
Pick total capacity first, then buy it as two modules: 2 × 32 GB for 64 GB, 2 × 48 GB for 96 GB, 2 × 64 GB for 128 GB. Use four slots only when two modules cannot hold what you need, and accept lower speed and longer memory training. Adding a second kit later is a classic path to instability, because the kits were never validated together.
Data rate, CAS latency, and true latency
In DDR5-6000 CL30, the data rate is in megatransfers per second and CAS latency counts clock cycles. DDR transfers twice per clock, so first-word latency in nanoseconds is:
true latency (ns) = CL × 2000 / data rate (MT/s)
DDR5-4800 CL40: 40 × 2000 / 4800 = 16.7 ns
DDR5-5600 CL46: 46 × 2000 / 5600 = 16.4 ns
DDR5-6000 CL30: 30 × 2000 / 6000 = 10.0 ns
DDR5-6400 CL32: 32 × 2000 / 6400 = 10.0 ns
A higher CL on a faster kit is not automatically worse. CAS is only one timing, so use the formula to compare kits, not to predict what software sees.
For development the priority is capacity, then stability, then bandwidth, then latency, because a machine that swaps loses more than any timing can recover. CPU inference is the exception: for offloaded layers, tokens per second cannot exceed bandwidth divided by the bytes of weights read per token. With 30 GB of dense weights in RAM and 89.6 GB/s, the ceiling is about 3 tokens per second. Mixture-of-experts models read only the active experts, which lowers that cost but not the capacity needed.
XMP and EXPO: rated speed is an overclock
A retail kit stores JEDEC timings that boards use by default plus vendor profiles. Intel XMP 3.0 supports up to five profiles, three from the vendor and two rewritable, and AMD EXPO provides profiles tuned for Ryzen on AM5. Both vendors call this overclocking. Intel says XMP beyond specifications may void the processor warranty (Intel XMP), and AMD says memory outside its published specifications voids the AMD warranty (AMD EXPO).
The kit vendor validated the profile on certain boards, and your CPU's memory controller is a separate sample. For a work machine:
- Update board firmware first, because memory training code changes between releases.
- Enable the profile and let the first boot finish. DDR5 training after a memory change can take much longer than a normal boot.
- Run the stability tests below before trusting the machine with real work.
- On errors, drop to a lower data rate or the JEDEC default instead of raising voltages by guesswork.
Running at the CPU's official speed is a legitimate choice for a machine that must be correct more than fast.
CUDIMM and the clock driver
A CUDIMM is an unbuffered DIMM with a clock driver (CKD) on the module. JEDEC's DDR5CKD01 standard defines the driver that re-drives the clock for CUDIMM, CSODIMM, and CAMM modules (JEDEC DDR5 clock driver), which improves signal quality at high data rates.
Platform support decides whether it helps. Intel's brief for Core Ultra 200S lists DDR5-6400 for one CUDIMM per channel, and Intel's March 2026 announcement of Core Ultra 200S Plus raises that to DDR5-7200 and adds early support for four-rank CUDIMMs of up to 128 GB on select 800-series boards. Elsewhere, check the CPU specification and the board's memory list first. A CUDIMM is not a registered DIMM and has no side-band ECC unless the listing says so.
On-die ECC is not ECC memory
Every DDR5 chip has on-die ECC, which JEDEC lists among the features that enable advanced process nodes (JEDEC DDR5 standard). It corrects errors inside the DRAM array only. It does not protect the module, the connector, or the bus, and its corrections are not reported to the operating system. On-die ECC on an ordinary UDIMM describes DDR5 itself, not an ECC module.
Side-band ECC adds DRAM devices that store check bits for each subchannel. The memory controller checks every access, corrects what the code can correct, detects worse errors, and reports both to the operating system. That reporting is the real benefit: a rising corrected count on one DIMM is an early warning, while a machine without ECC just crashes or corrupts data now and then.
UDIMM, RDIMM, and keying
ECC UDIMMs are unbuffered and fit consumer and entry workstation boards whose platform supports ECC. RDIMMs add a registering clock driver and belong to server and high-end workstation platforms. DDR5 UDIMMs and RDIMMs are keyed differently, so they are not interchangeable and cannot be mixed.
Which platforms support real ECC
ECC works only when the CPU, the chipset, the firmware, and the modules all support it. As of September 2026:
- AMD Ryzen 9000 on AM5: AMD lists ECC as "Yes (Requires mobo support)" for models such as the 9950X. Confirm ECC UDIMM support in the board manual and check your exact CPU model, because AMD desktop families differ.
- AMD EPYC 4005 on AM5: server CPUs for the same socket, with DDR5 ECC support up to 192 GB.
- AMD Ryzen Threadripper PRO 9000 WX-Series: up to eight channels of DDR5 RDIMM with ECC enabled by default.
- Intel Core Ultra 200S: ECC requires both processor and chipset support (Intel ECC support article). Intel lists ECC as supported on W880 and not on Z890.
- Intel Xeon 600 workstation processors on W890: registered DDR5 with ECC.
After the first boot with ECC modules, verify that ECC is active rather than assuming it.
Laptops: soldered LPDDR5X and CAMM2
Most thin laptops use LPDDR5X soldered to the board or on the processor package. It is fast and efficient, but capacity is fixed at purchase, and some platforms cap it low: Intel's Core Ultra 7 258V lists 32 GB as its maximum. Buy the capacity you would otherwise upgrade to later.
Wide designs sit at the other end. AMD's Ryzen AI Max+ PRO 395 uses a 256-bit LPDDR5X-8000 interface with up to 128 GB, which gives 32 bytes × 8000 MT/s = 256 GB/s of theoretical bandwidth, two and a half times a dual-channel desktop at DDR5-6400. That is why such machines are interesting for local models, but nothing can be upgraded.
CAMM2 is the replaceable alternative. JEDEC's JESD318 standard, published in December 2023, defines DDR5 and LPDDR5/5X Compression Attached Memory Modules with a shared connector design. Availability depends on the laptop model, so look for CAMM2 or LPCAMM2 in the vendor specification. SO-DIMM laptops remain the simplest upgrade path.
Test stability with memtest86+ and read errors on Linux
Test every new kit, profile change, and firmware update that changes memory training. Memtest86+ is a free, open-source, stand-alone tester. The current release is v8.10 from May 2026, and one binary boots on UEFI and legacy BIOS (memtest86+). The binary is not signed by Microsoft, so disable Secure Boot for the test and enable it again afterwards. One complete pass tests all memory, and longer runs add confidence. If an overclocked system fails, retest at defaults, then module by module. It is a separate project from PassMark MemTest86.
Run one pass at JEDEC defaults when the machine is new, several passes after enabling a profile, then an in-OS load test:
sudo apt install stressapptest
# Test 75% of RAM for one hour with CPU-intensive copy threads
stressapptest -s 3600 -M "$(awk '/MemTotal/ {printf "%d", $2*0.75/1024}' /proc/meminfo)" -W
With ECC, Linux reports corrected and uncorrected errors through EDAC counters in sysfs (kernel EDAC documentation):
ls /sys/devices/system/edac/mc/
sudo dmesg | grep -i -E 'edac|ecc'
grep -H . /sys/devices/system/edac/mc/mc*/ce_count /sys/devices/system/edac/mc/mc*/ue_count
sudo apt install rasdaemon
sudo ras-mc-ctl --status
sudo ras-mc-ctl --error-count
An empty /sys/devices/system/edac/mc/ means no EDAC driver for this controller or ECC is off, whatever the module label says, and dmidecode -t memory shows only what firmware claims. Treat any uncorrected error as a hardware incident and a rising corrected count on one DIMM as a reason to replace it. Newer rasdaemon releases move these options under subcommands, so check ras-mc-ctl --help.
Recommended configurations by use case
These are starting points, and your measured peak overrides them.
| Use case | Capacity | Configuration | Notes |
|---|---|---|---|
| IDE, browser, a few containers | 32 GB | 2 × 16 GB | Upgrading means replacing both modules |
| Containers, Kubernetes in Docker, parallel agents | 64 GB | 2 × 32 GB | Raise Docker Desktop or WSL limits |
| Several VMs, large databases, monorepo builds | 96 to 128 GB | 2 × 48 GB or 2 × 64 GB | Stay at one DIMM per channel |
| Local LLMs with CPU offload | 128 GB or more | 2 × 64 GB or a wider platform | Bandwidth caps offloaded speed |
| Costly silent corruption | 64 GB or more, ECC | ECC UDIMM on AM5 or W880, RDIMM on Threadripper PRO or Xeon | Verify EDAC counters |
| Laptop | 32 GB, 64 GB for VMs | LPDDR5X, SO-DIMM, or LPCAMM2 | Buy final capacity if soldered |
Beyond 128 GB, a two-channel desktop needs four modules at a lower official speed, which Threadripper or Xeon avoids.
A practical checklist before you order
- Log memory and pressure for a representative week and add headroom.
- Buy the total capacity as one kit of two identical modules.
- Check the CPU memory table and the board's memory list for the exact type: UDIMM, CUDIMM, ECC UDIMM, or RDIMM.
- Compare kits by true latency in nanoseconds and by data rate.
- Update firmware, enable XMP or EXPO only if you will test it, and let training finish.
- Run memtest86+ at defaults and with the profile, then an in-OS load test.
- For ECC, confirm platform support, then check EDAC counters in Linux.
- On a soldered laptop, buy the capacity you will need at the end of its life.
- Recheck memory pressure after a few months, especially after adding VMs, clusters, or local models.