The buffer pool's role in database IO

WHY IT EXISTS Disk and SSD access is orders of magnitude slower than RAM, yet databases manage far more data than fits in memory. The buffer pool exists to keep hot pages in RAM so most reads and writes touch memory, not disk.

THE MENTAL MODEL The database file is a collection of fixed-size pages. The buffer pool is a region of RAM divided into frames that each hold one page. The buffer manager mediates all page access: code asks for a page by id, and the manager either returns the cached copy or loads it from disk into a free or evicted frame.

HOW IT WORKS On a read, if the page is in the pool it is a hit and served from RAM; on a miss the manager fetches it from disk, possibly evicting another page first. On a write, the manager modifies the in-memory page and marks it dirty rather than writing through to disk immediately; the change is made durable by the write-ahead log, and the dirty page itself is flushed later by a background process or at a checkpoint. Pages are pinned while in use so they are not evicted mid-operation. When frames are exhausted, an eviction policy such as LRU, clock, or LRU-K selects a victim, flushing it first if dirty.

WHEN IT MATTERS Buffer pool size is one of the most important tuning knobs; a pool large enough to hold the working set turns disk-bound workloads into memory-bound ones. Hit ratio and dirty-page flush rate are key health signals.

LIKELY FOLLOW-UPS How does WAL let dirty pages flush lazily, what is a checkpoint, why use LRU-K or clock over plain LRU, and how does this differ from the OS page cache.

ONE CONCRETE EXAMPLE A query updating a row loads the page into the buffer pool, modifies it in memory, logs the change to the WAL for durability, and returns; the dirty page sits in RAM and is flushed to the data file minutes later at a checkpoint, so many updates to the same page cost one eventual disk write.