persistent memory
For decades computers have lived with a sharp split: fast memory (RAM) that is wiped the instant the power goes off, and slow storage (disk or SSD) that keeps your data but is far slower to reach. Programs constantly shuttle data across this gap. Persistent memory is a newer kind of hardware that blurs the line: it is nearly as fast as RAM and attached to the memory bus like RAM, yet it keeps its contents when the power is cut, like storage. It is as if your desk could remember everything left on it overnight, with no need to file it away in a cabinet first.
Technically the CPU can read and write persistent memory directly with ordinary load and store instructions, byte by byte, instead of issuing slow block-based reads and writes to a disk through the file system. This collapses a whole layer: a data structure can simply live in persistent memory and still be there after a reboot or a crash, with no separate save step. But this power brings a subtle hazard. The CPU's caches still sit in front of memory, so a write may linger in a volatile cache and be lost on a crash even though the program thought it was stored. Software must therefore use special flush and ordering operations to force data all the way down to the durable medium in the right order, which is genuinely tricky to get right — a half-finished update can leave a persistent data structure corrupted in a way ordinary memory never could.
The honest framing is that persistent memory does not magically make crash-safe programming free; it changes where the hard part lives. The operating system and file systems must be redesigned to expose byte-addressable persistence safely, and applications must reason carefully about durability and ordering. It is a genuine frontier that rethinks the age-old memory-versus-storage boundary, but it adds new failure modes even as it removes the old slow gap.
A database keeps its index in persistent memory. After a sudden power loss the machine reboots and the index is simply there, intact, with no slow reload from disk — provided the database used flush instructions to push each update all the way to the durable medium in order. Skip those flushes and a crash mid-update can leave the index silently corrupted.
RAM-fast yet power-safe — but only if writes are flushed in the right order.
Persistent memory does not make durability automatic. Because CPU caches sit in front of it, a write can be lost on a crash unless software explicitly flushes and orders it — a new and easy-to-get-wrong source of corruption.