How does persistent memory reshape redo logging architecture?

How does persistent memory reshape redo logging architecture?

Persistent Memory (PMEM), such as CXL-based memory modules or Intel Optane (used in Exadata), fundamentally reshapes this by moving the redo log from the "Storage Tier" to the "Memory Tier."


1. From "Block I/O" to "Byte-Addressable" Stores

Traditional redo logging is Block-based. When you commit, the OS must:

  1. Context switch from User Mode to Kernel Mode.

  2. Package the redo entry into a 512-byte or 4KB block.

  3. Send that block over the PCIe bus to an NVMe controller.

  4. Wait for the NAND flash to acknowledge the write (even with cache, this is a "heavy" operation).

The PMEM Shift: PMEM is byte-addressable. The Database can write a 128-byte redo entry directly to the PMEM DIMM using a simple CPU STORE instruction.

  • Result: No context switches, no block headers, and no filesystem overhead. You are writing at the speed of the memory bus.


2. The Death of "Log File Sync" Latency

In a 1M TPS environment, the log file sync wait event is usually the top performance killer.

  • Legacy NVMe Latency: $\sim$100$\mu$s – 200$\mu$s.

  • PMEM Latency: <0.5$\mu$s.

By placing the Redo Log Buffer directly on PMEM (or using PMEM as a "Log Buffer Cache"), the latency of a commit drops by 200x. This allows the Log Writer (LGWR) to process an order of magnitude more transactions per second because it no longer spends $99\%$ of its time waiting for the "Write Complete" signal from a disk controller.


3. Remote Persistent Memory (RPMEM) and RDMA

In a cluster, the redo log must be mirrored to a second node for high availability. In 2026, we use RDMA-to-PMEM.

  1. Node A performs a transaction.

  2. Node A uses RDMA Write to push the redo entry directly into Node B's PMEM.

  3. Because it’s RDMA, Node B’s CPU is never involved.

  4. Because it’s PMEM, the data is instantly "safe" (persistent) the moment it hits the memory controller.

This creates a Global Persistent Store where commits are finalized across the network in less time than it used to take to write to a local SSD.


4. Architectural Impact: The "Slimmer" LGWR

Because PMEM is so fast, the way we model the Log Writer (LGWR) changes:

  • Fewer LGWR Processes: We no longer need a "swarm" of worker processes to manage I/O queues. A single, high-priority LGWR can handle millions of transactions because there is no queueing at the storage layer.

  • Elimination of "Adaptive Log Writing": The system no longer needs to switch between "Post/Wait" and "Polling" methods to find the best performance; the hardware is consistently at the theoretical limit of the physics.


5. Summary: Redo Evolution

MetricSSD / NVMe RedoPersistent Memory (PMEM) Redo
Write UnitBlock (512B+)Byte (Variable)
Access MethodSystem Call (I/O)CPU Store / Load
Commit LatencyMilliseconds/MicrosecondsNanoseconds
CPU OverheadHigh (Context Switching)Near Zero
1M TPS StabilityVulnerable to "I/O Spikes"Perfectly Deterministic

The Verdict

Persistent Memory doesn't just make redo logging "faster"—it makes it architecturally invisible. By removing the distinction between "Memory" and "Storage," PMEM allows the database to achieve 1M TPS with a level of efficiency that makes traditional NVMe-based systems look like tape drives.

Looking for servers Rental ?

Call Our Expert :


  • (call for rental enquiries)

Email us :