A single DRAM bank is painfully slow. Once you activate a row (ACT), you must wait tRC (row cycle time, ~45–50 ns on DDR4) before you can activate another row in that same bank. During tRC the sense amplifiers are busy latching, restoring charge to the leaky capacitors, and precharging the bitlines back to V/2. If your workload only touched one bank, peak bandwidth would collapse to roughly one row every 50 ns — a few hundred MB/s, not the 25 GB/s the datasheet promises.

The fix is bank-level parallelism. A DDR4 chip has 16 banks (4 bank groups × 4 banks). Each bank has its own row buffer and its own sense-amp array, so activations can proceed independently and in parallel. While bank 0 is grinding through its tRC, the controller issues ACT to bank 1, then bank 2, then bank 3 — and by the time bank 3 is activated, bank 0's row buffer is ready to serve column reads (CAS). The shared data bus is kept full even though every individual bank is idle most of the time.

Concrete example: Consider a DDR4-3200 chip with tRC = 47 ns, tRRD_S (activate-to-activate, different bank group) = 3.3 ns, and burst length 8 (BL8 = 5 ns on the bus). With one bank you get one 64-byte burst every 47 ns → 1.36 GB/s. With 16 banks staggered, you can issue an ACT every tRRD_S and a CAS every ~5 ns, saturating the 25.6 GB/s bus — a ~19× speedup from the same silicon.

Bank groups add a second layer. Within a group, back-to-back CAS commands are limited by tCCD_L (~6.25 ns); across groups it's tCCD_S (~3.75 ns). So the controller prefers to interleave requests across bank groups first, then across banks within a group. Address hashing at the controller (typically XOR-folding a few address bits into bank-group select) spreads sequential access patterns across all 16 banks so a linear memcpy naturally hits every bank in rotation.

Rule of thumb: Achievable DRAM bandwidth ≈ min(bus_peak, N_banks × burst_size / tRC). If N_banks × 64B / 47ns exceeds bus_peak, you're bus-bound (good — you can't do better). If it's less, you need more parallelism: more banks, deeper request queues, or better address hashing. GPUs push this to extremes with HBM stacks that expose 128+ pseudo-channels — each one an independent bank — precisely because a single bank's tRC hasn't improved in 20 years.