How much RAM do you actually need? Measure it, then decide

Almost every answer to this question is a number with no reasoning behind it — 16 GB for general use, 32 for creative work, 64 if you are serious. Those numbers are not wrong exactly, but they describe a hypothetical person rather than you, and your machine already holds the real answer.

Free memory is not the metric

The most common mistake is reading "free" memory and concluding the machine is nearly out. Modern operating systems deliberately fill unused RAM with cached file data, because empty memory does no work. On a healthy Linux machine running for a week, free memory approaching zero is normal and desirable.

The number that matters is available: how much the kernel could hand to a new process immediately, by evicting cache. On Linux:

free -h
#               total        used        free      shared  buff/cache   available
# Mem:           31Gi        9.2Gi       1.1Gi       412Mi        21Gi        21Gi

That machine looks almost full and is not. 21 GB is available; the cache gives it back on demand.

The signal that you are actually short

Pressure shows up as paging, not as a low number. Watch the swap columns:

# si = swapped in, so = swapped out, per second
vmstat 1 30

Occasional swap-out with no swap-in is harmless — the kernel is moving cold pages aside. Sustained non-zero si is the problem: the system is reading pages back, which means it evicted something it still needed. That is the state that feels like a slow computer.

Linux also exposes pressure directly, which is more honest than inferring it:

cat /proc/pressure/memory
# some avg10=0.00 avg60=0.00 avg300=0.00 total=0
# full avg10=0.00 avg60=0.00 avg300=0.00 total=0

Anything consistently above zero on some avg60 means tasks are stalling on memory. This is the single clearest answer to "do I need more RAM", and it needs no interpretation.

On macOS, read memory pressure and compression

macOS compresses memory rather than swapping to disk first, so "memory used" is misleading in a different way. Activity Monitor's Memory Pressure graph is the real indicator — green means fine regardless of how full the bar looks.

memory_pressure          # a running summary
vm_stat 5                # watch "Pages stored in compressor" climbing

Steady growth in compressed pages under normal work, and a pressure graph leaving green, is the point at which more RAM helps. A full-looking memory bar on its own is not.

On Windows, the number to watch is committed

Task Manager's "In use" figure under-reports demand. Open Resource Monitor and look at Commit — the total memory applications have asked the system to guarantee. When commit regularly exceeds physical RAM, Windows is backing the difference with the page file, and that is where the stutter comes from.

The Hard Faults/sec counter is the equivalent of Linux's swap-in: sustained non-zero values under ordinary use mean you are short.

Measure your actual peak, not your idle

Run your real workload — the browser with the tabs you genuinely keep open, the IDE with your project loaded, the containers you run — and record the peak rather than glancing once.

# Linux: sample available memory each second for ten minutes, keep the minimum
for i in $(seq 1 600); do
  awk '/MemAvailable/ {print $2}' /proc/meminfo
  sleep 1
done | sort -n | head -1 | awk '{printf "lowest available: %.1f GB\n", $1/1048576}'

If the lowest available figure across a realistic session stays above a few gigabytes and pressure stays at zero, you have enough. If it approaches zero and swap-in appears, you do not.

What genuinely changes the answer

A handful of workloads move the requirement by a lot, and most do not.

• Virtual machines and containers. Memory assigned to a VM is gone from the host for its lifetime. This is the single biggest multiplier for most people.
• Local language models. Model weights sit in memory while loaded — several gigabytes for a small quantised model, tens for a large one. If you run these, the model size dominates everything else on this list.
• Working with large files. Video editing, large datasets, image stacks. The file size is the floor.
• Many browser tabs. Real but usually overstated — modern browsers discard inactive tabs and reload them.
• Compiling large projects. Parallel builds multiply per-process memory by core count, which is how a 16-core machine runs out of memory on a build that works fine on four cores.

What does not meaningfully change it: a faster CPU, a larger SSD, or the number of applications installed.

Speed and channels, briefly

Capacity is almost always the thing that matters, with one exception worth knowing: memory channels. A machine with two matched sticks has roughly double the bandwidth of one stick of the same total capacity.

That rarely matters for ordinary work and matters a great deal for integrated graphics, which have no dedicated video memory, and for running language models on CPU, where generation speed is bounded by memory bandwidth almost directly. If either applies to you, two smaller sticks beat one larger one.

# Linux: how many channels are actually populated
sudo dmidecode -t memory | grep -E 'Size|Locator|Speed' | head -20

A decision you can defend

1. Run your real workload and record the lowest available memory and whether pressure ever left zero.
2. If pressure stayed at zero, you have enough. Spend the money elsewhere.
3. If it did not, take your peak usage, add the largest single thing you plan to add — a VM, a model — and round up to the next standard size.
4. Check upgrade headroom first. Soldered memory means the decision is permanent; two free slots means you can defer it.
5. Populate channels in pairs, particularly with integrated graphics.

The honest summary: most people asking this question already have enough and are experiencing a different bottleneck, usually storage. The measurement takes ten minutes and tells you which camp you are in.