Buffer Pool & Page Cache
The problem
Reading from disk on every single query would make even simple lookups unacceptably slow — a database needs to keep frequently accessed data in memory, deciding intelligently what to keep and what to evict as memory fills up, without simply running out of RAM.
Why now
Virtual memory already established that the OS manages a page cache mediating between fast RAM and slow disk; a database's buffer pool is that same idea, implemented a second time at the application level because the database can make smarter, workload-aware eviction decisions than a general-purpose OS cache can.
Mental model
A buffer pool is a fixed-size cache of disk pages held in memory, with an eviction policy (commonly a variant of least-recently-used) deciding what to discard when it's full and new data needs to be loaded — the exact cache/eviction tradeoff virtual memory already introduced for OS-level paging, just re-implemented with database-specific knowledge of which pages are actually likely to be reused soon.
Requires
- Virtual MemoryOperating Systems
A buffer pool is a database-managed cache sitting between the database and disk, directly analogous to (and often layered on top of) the OS's own virtual-memory page cache; you need that caching/eviction concept already established before a second, workload-aware cache on top of it makes sense.
- Storage Engines: B-Tree vs. LSM-TreeDatabase Engineering
What the buffer pool caches is exactly the on-disk pages the storage engine reads and writes; you need the storage engine's page-based structure already understood before reasoning about which pages are worth keeping in memory.
Used in
- PostgreSQL's shared_buffers and MySQL's InnoDB buffer pool, both tunable, central performance parameters
- Diagnosing slow queries caused by a buffer pool that's too small for the working data set (constant disk reads)
- Cache hit ratio as one of the most important database health metrics to monitor
- Explaining why a database's first query after a restart is often much slower than subsequent identical queries (a cold cache)
Projects
- Run the same query twice — once against a cold buffer pool (just after restart) and once warm — and measure the latency difference directly
- Tune a database's buffer pool size for a given working data set size and explain the reasoning using cache hit ratio
Examples
- A query that reads 10,000 pages already sitting in the buffer pool completes almost instantly; the same query against a cold cache pays a disk read cost for every single page
- A buffer pool sized smaller than the actively-queried working set causes constant eviction and reload — thrashing, the same failure mode virtual memory already named for OS-level paging
Resources
Mastery checklist
- I can explain what a buffer pool caches and why it exists alongside the OS page cache
- I can explain a least-recently-used-style eviction policy
- I can diagnose a performance problem caused by an undersized buffer pool
- I can explain why cache hit ratio is a key database health metric