SRAM, DRAM, NOR, NAND, EEPROM, FRAM, MRAM, eMMC: memory types and how to choose
There's no memory that is "non-volatile, rewritable, and fast" all at once. Every memory has given up on endurance, capacity, speed, or price. What you can afford to give up is a function of the application, so this is organized to be looked up by application.
Start with three groups
It helps to split memory into three groups: volatile memory that loses its contents when power is removed (SRAM, DRAM); the flash family that retains data but can only be erased in blocks (NOR, NAND, EEPROM, eMMC); and the newer non-volatile types that retain data and can be written byte by byte (FRAM, MRAM).
SDRAM is a kind of DRAM (the synchronous kind), and DDR is a generation name within that. eMMC puts a controller on top of NAND in a single package — inside, it's still NAND. "Flash" is the umbrella term for NOR and NAND; EEPROM shares the same floating-gate principle, but the byte-erasable, byte-writable variant is called out separately as EEPROM.
| Type | Volatile | Capacity | Write granularity | Endurance | Write time | Typical use |
|---|---|---|---|---|---|---|
| SRAM | Yes | Few kB–few MB | Byte | Unlimited | Few ns | MCU RAM, cache |
| DRAM / SDRAM / DDR | Yes | 64MB–few GB | Byte (burst) | Unlimited | Tens of ns | Main memory for an OS |
| NOR flash | No | 1MB–256MB | Write: byte, erase: sector (4k–64kB) | 100k cycles | Write µs, erase 100s of ms | Boot code, XIP |
| NAND flash (raw) | No | 1GB–few TB | Write: page (few kB), erase: block (MB) | SLC 100k, TLC 3k | Write 100s of µs, erase few ms | Bulk data |
| eMMC | No | 4GB–256GB | Sector (512B, NAND inside) | Managed by controller | 100s of µs+ | Linux root FS |
| EEPROM | No | 1kbit–4Mbit | Byte | 1M cycles | 5ms (page) | Settings, calibration |
| FRAM | No | 4kbit–16Mbit | Byte | 10¹⁴ cycles | Tens of ns (no wait) | Frequently-written settings, logs |
| MRAM | No | 1Mbit–1Gbit | Byte | Unlimited (10¹⁵+) | Tens of ns | Non-volatile SRAM replacement |
Volatile: SRAM and DRAM
SRAM is a flip-flop, six transistors per bit. It holds its state as long as power is applied, needs no refresh, and reads and writes in a few ns given an address. The cell is large, so cost per bit is high — tens to hundreds of kB on-chip in a microcontroller, a few MB at most for external parallel SRAM.
DRAM is one transistor and one capacitor per bit. The capacitor's charge leaks, so it must be read and rewritten (refreshed) every few tens of ms. The cell is small, so gigabytes are cheap. SDRAM is DRAM that bursts data synchronously to a clock; DDR / DDR2 / 3 / 4 / 5 and their low-power siblings, LPDDR, are generations of it.
Using DRAM requires a memory controller on the processor side to handle refresh, bank management, and timing. A microcontroller without one cannot connect to DRAM. Conversely, any processor that runs Linux always has a DDR controller and assumes DRAM as main memory from a few hundred MB up.
The rule of thumb is simple: SRAM for a few MB or less, DRAM above that. The awkward middle ground — "I want a few MB of SRAM" — doesn't pencil out on price, so QSPI pseudo-SRAM (PSRAM, DRAM inside with refresh built in) fills that gap.
The flash family: NOR, NAND, EEPROM, eMMC
Flash stores data by trapping electrons in a floating gate. Writing (adding electrons) can be done bit by bit, but erasing (removing electrons) can only be done in a fixed-size block. Remember it as "you can turn a 1 into a 0, but turning a 0 back into a 1 needs an erase," and almost every constraint below follows from that.
NOR flash connects its cells in parallel, so any address can be read at random. The processor can execute instructions straight from it (XIP, Execute In Place), which makes it the natural home for boot code and firmware. SPI/QSPI parts from 1 to 256MB are the norm. Erase happens in sectors (4kB–64kB) and takes hundreds of ms; endurance is around 100k cycles.
NAND flash chains its cells in series to pack in more density, so reads and writes happen only in pages (a few kB) and erase happens in blocks (hundreds of kB to a few MB). Bit errors are routine, so ECC and bad-block management are mandatory. Endurance runs 100k cycles for SLC (1 bit/cell), 10k for MLC, 3k for TLC, and 1k for QLC — more bits per cell means cheaper but weaker endurance.
eMMC puts a controller on top of NAND that handles ECC, wear leveling, and bad-block management internally. From the outside it just reads and writes 512B sectors over the same MMC interface as an SD card. It's the standard choice for a Linux root filesystem, sparing you the work of handling raw NAND directly (MTD + UBI on Linux).
EEPROM is non-volatile memory built to erase and write byte by byte. Capacity is small (a few kbit to a few Mbit), a write takes about 5ms, but it survives a million write cycles and costs pennies over I²C/SPI. It's where settings, calibration data, and serial numbers live.
A design that "stores settings in flash" runs straight into the erase-granularity and endurance limits. Erase a 4kB sector every time you rewrite 16 bytes of settings and you hit the 100k-cycle limit in weeks. Either implement your own wear leveling (rotate the write location within the sector) or keep settings in a separate EEPROM or FRAM — the safer bet.
FRAM and MRAM: byte-writable non-volatile memory
FRAM (ferroelectric RAM) stores data as the polarization direction of a ferroelectric material. Like SRAM, it writes byte by byte with no wait (write cycle of tens of ns) and survives 10¹⁴ write cycles. There's no 5ms write wait like EEPROM, and a power loss mid-write doesn't corrupt the data. Capacity tops out around 16Mbit and it costs more than EEPROM. Reading destroys the polarization, so it's rewritten internally on every read, which technically caps read cycles too — but at 10¹⁴, that's unlimited in practice.
MRAM (magnetoresistive RAM) stores data as the magnetization direction of a magnetic layer. Endurance is effectively unlimited, and some parts match SRAM's speed and interface, which is why it's used as a replacement for battery-backed SRAM. STT-MRAM reaches the 1Gbit class, but costs tens of times more than DRAM. Some parts are sensitive to strong magnetic fields, so mind the placement.
Both suit applications that write often, may lose power unexpectedly, and don't need much capacity: running totals, operating hours, recent event logs, state saved on power loss. Doing the same thing in flash needs wear leveling and journaling against power loss — building that usually costs more than just adding one FRAM chip.
Choosing by application
- Boot code / firmware. On-chip MCU flash if it's big enough, otherwise QSPI NOR — chosen for XIP capability and fast random reads. NAND is paired with a small boot NOR, or you use eMMC's boot partition.
- Working memory. On-chip SRAM up to a few hundred kB; PSRAM or external SRAM for a few MB; DDR above that (assumes a processor with a memory controller).
- Settings / calibration data (written a few times a year to a few times a day). I²C EEPROM. Emulating it in on-chip MCU flash works too, but calculate the erase count and granularity.
- Running totals / counters / state (written every second to every minute). FRAM or MRAM. EEPROM burns through its million cycles in a few weeks at that rate.
- Logs / measurement data (large volume, append-only). SPI NAND, eMMC, or an SD card. Raw NAND means committing to your own ECC and bad-block management.
- An OS filesystem. eMMC. SD cards bring insertion/removal wear and quality-control risk, so eMMC is standard in production.
- The last-known state that must survive a power loss. FRAM or MRAM — a power loss mid-write doesn't corrupt the data.
Common mistakes
- Writing to flash every second. Hits the erase-cycle limit within days. Switch to FRAM, or buffer in RAM and write less often.
- Not waiting for an EEPROM write to finish. A write or read during the 5ms write window gets no response (wait it out with ACK polling).
- Power loss mid-write. Both flash and EEPROM leave the page in an undefined state if power drops during a write. Write alternately to two locations and pick the valid one by CRC, or use FRAM instead.
- Using raw NAND without ECC. Bad blocks exist from the factory and bits flip in use. ECC is mandatory even for SLC.
- Ignoring eMMC's lifespan. It's TLC NAND inside, with a cap on total bytes written (TBW). For high-frequency logging, calculate the lifespan and consider SLC mode or an industrial-grade part.
- Underestimating DRAM routing. DDR3 and above need length matching, controlled impedance, and termination — tough on a 4-layer board. Consider a memory module (SOM) as an alternative to routing it yourself.
- Placing a magnet near MRAM. Some parts corrupt data near a speaker, relay, or Hall-sensor magnet. Check the datasheet's field immunity.
Frequently asked questions
What's the difference between EEPROM and flash?
Are SDRAM and DDR different things?
What's the difference between eMMC and an SD card?
Should I choose FRAM or MRAM?
Standards and references
- JEDEC JESD79 series / JESD84 (eMMC) — DDR SDRAM and eMMC standards
- ONFI (Open NAND Flash Interface) specification — Raw NAND interface and ECC requirements
- Individual memory vendors' datasheets — Endurance, data retention, write time, TBW