What Is RAM (and Why Does Your App Run Out of Memory)?

Quick answer
RAM is the temporary workspace: every program you are running, and the data it is working on, lives there. Turn the power off and it is gone.
Storage keeps data permanently but is thousands of times slower to reach, so the CPU works out of RAM and pulls from disk only as needed.
Capacity is what kills apps. When RAM runs out the operating system starts killing processes, and in a container you hit a memory limit instead.
Bandwidth and latency are separate specs: two memory channels roughly double how much data per second you can move, while latency barely changes.
ECC memory detects and corrects the rare bit flips that silently corrupt data. Servers have it, most laptops do not, and it is why server memory costs more.

What is RAM?

RAM (random access memory) is the working memory of a computer: a large, fast, temporary store that holds the code and data of everything currently running. When you start a program, its instructions and its working state are loaded into RAM. When the program needs a value, it asks for an address and gets the contents back. The CPU does its thinking out of RAM and its registers, never directly out of the disk.

The word to hold onto is volatile. RAM keeps its contents only while powered. Storage — the SSD or hard drive — is where data lives permanently, and the entire point of the two-tier design is that storage is far cheaper per gigabyte but thousands of times slower to reach. The same file can therefore be ‘in memory’ (fast, temporary) or ‘on disk’ (slow, permanent), and the whole job of a database, a cache, and an operating system is deciding what to keep in the fast tier.

Why running out of RAM is fatal and slow disk is not

Running out of disk space is annoying; running out of memory is an outage. The reason is that when RAM fills up, there is no slower place to put the overflow that is fast enough to keep working. On Linux the kernel has an out-of-memory killer that terminates processes to free space, chosen by a heuristic that likes to sacrifice the largest consumer. In a container or pod, the same thing arrives earlier and cleaner: exceed the memory limit and the container is killed with an OOMKilled status, with no chance to log a goodbye.

There is a middle ground called swap — a section of disk the kernel uses as overflow memory. It prevents an immediate kill but the machine becomes almost uselessly slow, because every access to swapped data pays the disk latency. Under a container runtime, swap is usually disabled or limited, so the choice is between fitting in memory and being killed. If you have seen an app die at exactly the same point every time it processes a large file, this is the first thing to check.

Bandwidth, channels, and latency

Modern memory is DDR — double data rate — and the generation (DDR4, DDR5) plus the speed rating (for example DDR5-5600) determine how fast data moves. Two numbers matter and they are not the same thing. Bandwidth is how much data can be transferred per second, measured in gigabytes per second; latency is how long a single request takes, measured in nanoseconds. Bandwidth is raised by increasing the data rate and by installing memory in pairs so the controller can use two channels at once — which is why adding a second identical stick often helps more than replacing one stick with a faster one.

Latency, on the other hand, has barely improved in decades: it sits at roughly 80 to 100 nanoseconds, which sounds tiny until you remember a CPU cycle is about a third of a nanosecond. Servers take a different route entirely: instead of chasing bandwidth per core, they have many memory channels feeding many cores, so that dozens of threads can each pull data at once without fighting over the same pipe. GPUs go further still, using soldered high-bandwidth memory with several times the bandwidth of desktop RAM — the reason a graphics card’s memory is the specification that decides which AI models fit.

ECC memory, and why servers pay for it

Memory can flip a bit. Cosmic rays and electrical noise occasionally change a 0 to a 1 in a way no software asked for, and with several gigabytes being read and written billions of times a second, it happens more often than a clean-sounding design suggests. On a laptop, that usually means a mysterious crash or a subtly wrong number. On a machine holding a database or a customer’s bank balance, silent corruption is unacceptable.

ECC (error-correcting code) memory carries enough extra bits to detect and correct single-bit errors, and to detect — and refuse to use — most multi-bit ones. It has to be supported by the memory controller, which is why consumer processors and laptops generally do not offer it while server platforms require it. The cost is a modest premium and, sometimes, a small bandwidth penalty. If a machine’s job is to hold state other people depend on, ECC is one of the concrete differences you are paying for when you rent a server instead of a PC.

How much memory do you actually need?

Start from the operating system and add measured usage, not guesses. A modern desktop wants 8 GB to feel comfortable and 16 GB to be pleasant with a browser, an editor, containers, and a language server open. A small Linux server runs the OS and a handful of services in 1 to 2 GB. A database needs enough memory to hold its working set and indexes so it does not read from disk on every query, which is usually far more than the CPU it is paired with is worth.

Then measure rather than estimate. On Linux, free -h shows total, used, and — the number to watch — available, which is how much memory a new process could claim right now. Watch it under real load, including the peak, and size for the peak. The failure mode you are avoiding is not steady-state discomfort, it is the day a large import or a spike in concurrency pushes usage past the ceiling and something important gets killed. Sizing containers is the same exercise with a hard number attached; the memory-limit guide covers what happens when you set it wrong.

# Watch real usage, not the number in the spec sheet
free -h            # 'available' is the figure that matters, not 'free'
vmstat 1           # si/so columns show swap being used: bad news

# Per-process memory, biggest first
ps -eo pid,rss,comm --sort=-rss | head

Where this bites vibecoders
Memory is the resource AI-generated code is worst at respecting. A script that loads a whole dataset into a list, builds an in-memory index of every row, or caches every response ‘for speed’ works beautifully on a development machine with 32 GB and gets killed on a 512 MB container. The assistant cannot see the ceiling you will deploy under, and the code contains no clue that one exists. Reading what actually allocates — the list, the cache, the unbounded queue — and asking what happens when it grows is the check that turns a demo into something that survives contact with real data.

Where AI coding assistants get this wrong

Loading an entire table or file into memory instead of streaming or paginating it.
Adding an unbounded in-memory cache that grows with traffic.
Setting a container memory limit below the app’s real peak, then treating OOMKilled as a random restart.
Assuming swap will save the machine, when containers usually have none.
Confusing storage with memory, so a disk-space check is mistaken for a memory check.
Ignoring that a memory leak looks fine until the day it crosses the limit.

Checklist

Watch ‘available’ memory under real load, at the peak, not at idle.
Make sure containers have a memory limit and the app fits it with headroom.
Replace whole-file loads with streaming or paginated reads.
Cap or remove unbounded in-memory caches.
Treat a rising memory curve as a leak, not a sizing problem.
For databases, check that the working set and indexes fit in memory.
Keep a monitoring alert on memory before it reaches the limit.

FAQ

Is RAM the same as storage?

No. RAM is temporary working memory that loses its contents when powered off, and it is where running programs live. Storage (SSD or hard drive) keeps data permanently and is much slower to reach. A computer needs both: memory to work in, storage to remember in.

Why does my app get OOMKilled instead of slowing down?

Because there is no fast enough fallback. When a container exceeds its memory limit, the kernel terminates a process to protect the machine, which the runtime reports as OOMKilled. Swap would avoid the kill but make everything unacceptably slow, so containers generally run without it. The fix is to reduce peak usage or raise the limit.

Does more RAM make a computer faster?

Only up to the point where the working set fits. Beyond that, more capacity changes nothing about how fast each access is. What does help is having enough that the machine is not constantly shuffling data to disk, and using matched pairs of sticks so both memory channels are populated.