JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

SRAM vs DRAM: Speed, Density, Cost

The cache rung kept calling one memory fast-but-tiny and another big-but-slow. Now we open the lid and meet the two devices themselves — SRAM and DRAM — and see exactly why one is six transistors of speed and the other one transistor of cheapness that has to be refreshed before it forgets.

Two ways to remember a bit

All through the cache rung we leaned on a convenient shorthand: SRAM is the fast-but-tiny stuff caches are built from, DRAM is the big-but-slow main memory below. That was true, but it was a label, not an explanation. This rung opens the chips themselves. The whole split between them comes down to one question asked of every single transistor on the die: *how many transistors are we willing to spend to remember one bit?* Answer 'six' and you get speed. Answer 'one' and you get cheapness. Everything else — the price, the density, the refresh, the memory wall — flows from that one choice.

SRAM — static random-access memory — stores each bit in a little loop of two inverters that hold each other's state, locked into one of two stable positions. It is the same bistable trick a register file uses, which is exactly why register files and L1 caches are made of it. Because the loop actively holds itself, the bit stays put as long as power is on, with no maintenance — that is the 'static' in its name. The price is size: a classic SRAM cell takes six transistors, so for every bit you are paying for six switches and the wires that join them.

DRAM — dynamic random-access memory — refuses to spend six transistors. It stores each bit as a charge on a tiny capacitor, guarded by a single access transistor: charged means 1, empty means 0. One transistor and one capacitor per bit. That is roughly six times denser than SRAM at the cell level, which is the entire reason your machine has gigabytes of DRAM but only megabytes of cache. But a capacitor is a leaky bucket — the charge drains away in milliseconds — so DRAM is 'dynamic': left alone, it forgets. We will pay for that leak in the very next section.

The leak, and the cost of remembering

Because the DRAM capacitor leaks, the chip must periodically read every row and write the charge back, topping it up before it falls below the threshold that separates a 1 from a 0. This housekeeping is called refresh, and it happens automatically, typically once every 64 milliseconds for the whole array. Refresh is the tax DRAM pays for its density: it costs a little energy, and now and then a row is busy being refreshed exactly when the processor wants it, adding a small stall. SRAM owes no such tax — its bits hold themselves — which is half of why SRAM is faster, not just smaller.

There is a deeper reason SRAM responds faster, beyond owing no refresh. An SRAM cell drives its output actively — the inverter loop pushes the bit line hard, so a read is quick and confident. A DRAM read is a delicate act of measurement: opening the access transistor lets the tiny stored charge tip a much larger bit line by a whisper, which a sense amplifier must detect and rebuild. That sensing takes time, and — because reading drains the capacitor — every DRAM read must immediately write the value back. SRAM shouts its bit; DRAM has to be carefully listened to.

Speed, density, cost — three numbers that fight

Now put the two side by side and the trade-off is stark. SRAM wins on latency by a wide margin — a few hundred picoseconds to a couple of nanoseconds inside a cache, versus tens of nanoseconds to reach a DRAM cell. DRAM wins on density and therefore on cost-per-bit, again by a wide margin, because one transistor beats six. You genuinely cannot have both: the very thing that makes SRAM fast (an active six-transistor cell) is the thing that makes it big and dear, and the very thing that makes DRAM cheap (a one-transistor charge cell) is the thing that makes it slow and forgetful.

                 SRAM                      DRAM
  ------------   -----------------------   -----------------------
  cell          ~6 transistors            1 transistor + 1 capacitor
  density       low  (big cell)           high (~6x denser)
  cost / bit    high                      low
  latency       very fast (<1-few ns)     slow (tens of ns to a cell)
  refresh?      no  (static, self-held)   yes (dynamic, leaks)
  volatile?     yes                       yes
  used for      register file, L1/L2/L3   main memory (the DIMMs)

  Same job (hold a bit) -- opposite engineering bargain.
  Six switches buy speed; one transistor buys cheapness.
SRAM versus DRAM at a glance. Exact timings vary by process and design; the shape of the trade — fast-and-costly versus dense-and-cheap — is what is universal.

This is precisely why the cache hierarchy exists at all, and the device facts you just learned are its foundation. We could never build main memory out of SRAM — a few gigabytes of six-transistor cells would be impossibly large and ruinously expensive. We could never build a cache out of DRAM and keep it fast. So architects use both: a thin skin of SRAM right against the pipeline for speed, a deep ocean of DRAM behind it for capacity, and the locality trick from the last rung to make the slow ocean feel fast most of the time. SRAM versus DRAM is not a contest with a winner; it is the reason the hierarchy has layers.

Reading a DRAM cell, step by step

It is worth walking one DRAM read slowly, because the rest of this rung is built on these motions. The cells sit in a grid of rows and columns; to read one bit you do not pluck it directly, you first haul its whole row up to a strip of sense amplifiers, then pick your column out of that strip. This grid-then-strip dance is exactly why DRAM has the row-and-column timing the next guide explores in detail.

  1. Open the row (activate). The controller selects one row; its access transistors connect every capacitor in that row onto the bit lines, gently nudging them up or down.
  2. Sense and latch. The sense amplifiers detect those tiny nudges, amplify each to a full 0 or 1, and hold the entire row in a fast on-chip buffer (the row buffer).
  3. Read the column. From that latched row, the controller selects the column it actually wants and ships those bits out. Reading more columns from the same open row is now cheap — the row is already up.
  4. Write back and close (precharge). Because sensing drained the capacitors, the amplifiers restore the charge, then the bit lines are reset so a different row can be opened next.

Notice the asymmetry hiding in step 3. Opening a row is the expensive part; once it is sitting in the row buffer, more bits from the same row come almost for free. That single fact — neighbouring bits are cheap once the row is open — is the device-level root of spatial locality paying off, and it is why memory is fastest when you stream through it in order rather than hop around. The cache rung told you locality matters; this is the physical machinery that rewards it.

Why the memory device sets the ceiling

Here is the honest, slightly deflating headline of this whole rung: very often, the memory devices set the performance ceiling, not the processor. A capacitor in a DRAM chip is governed by physics that barely improved while logic kept getting faster — which is exactly the memory wall from the cache rung, now seen from the device side. You can buy a CPU with twice the cores or a higher clock rate, but if your program waits on DRAM, those extra cores spend their lives stalled. This is why so much real-world performance work is about respecting memory, not out-clocking it.

Two honest caveats before we climb on. First, density does not buy speed: a denser, cheaper DRAM generation gives you more capacity and often more bandwidth, but the latency to a fresh row has barely budged in decades — capacity and latency are different axes, and conflating them is a classic mistake. Second, both these memories are imperfect. A cosmic ray or stray particle can flip a stored bit — a soft error — and in a machine with vast DRAM this is rare but real. Servers defend against it with ECC memory, which stores extra check bits so single-bit flips are caught and corrected, trading a little capacity for trustworthy data.