When your CPU writes to DRAM, the data doesn't just land in the row buffer and disappear into the array. The sense amplifiers have to drive the bitlines back to full voltage levels, and the storage capacitors have to actually receive that charge before the row can be closed. That recovery period is called tWR (write recovery time), and it's one of the most under-appreciated latencies in modern memory systems.

Here's the sequence the memory controller has to respect: a write command issues, data arrives on the bus over the burst length, and then tWR nanoseconds must elapse after the last data beat before a precharge command can close the row. Only after precharge can the bank open a new row. If you have writes followed by reads to different rows in the same bank, you pay this penalty every single time.

Concrete numbers (DDR5-6400):

• tWR ≈ 30 ns (the spec floor, independent of clock speed)
• Burst length: 16 beats at 3200 MHz = 5 ns of data transfer
• tRP (precharge): ~14 ns
• tRCD (row activate to column access): ~14 ns

So a write that closes a row and opens a new one costs you roughly 5 + 30 + 14 + 14 = 63 ns before the next read can return data. Compare that to a read-after-read in the same row: ~14 ns. That's a 4.5x penalty for the write-then-switch pattern.

Real-world example: Database transaction logs. A write-heavy workload that appends to a log and then reads metadata from a different page can hammer this exact pattern. PostgreSQL's WAL writer thread issuing fsync-driven flushes followed by readers walking the buffer pool used to show measurable stalls until tunables like wal_buffers and write batching let the controller coalesce writes within the same row before precharging. Per-write the cost looks invisible; at 200K TPS it becomes a wall.

Rule of thumb: If you can keep writes coalesced within a row before switching rows, you amortize tWR across many writes. The memory controller's write queue exists precisely to wait for enough same-row writes to accumulate before flushing — typically until the queue hits a high watermark (~75% full) or a write-to-read turnaround is forced by a starving read.

This is also why DDR5's per-bank refresh and finer bank groups matter: more banks means more chances that a write-recovering bank isn't the one a read needs right now. Bank-level parallelism literally hides tWR.