Radim Marek: Inside PostgreSQL's 8KB Page

Why It Matters

Understanding PostgreSQL's page layout helps DBAs optimize performance, estimate storage needs, and exploit features such as index‑only scans.

Key Takeaways

• PostgreSQL default block size is 8 KB, unchanged for 40 years
• Page header (24 bytes) stores LSN, checksum, visibility flags
• Line pointers map tuples, enabling HOT updates without index changes
• Free space lies between pd_lower and pd_upper offsets
• Changing block size requires compile‑time option and full rebuild

Pulse Analysis

The 8 KB page size in PostgreSQL traces back to the original Berkeley POSTGRES project, when Unix virtual memory pages were 4 KB or 8 KB and disk sectors were 512 bytes. Aligning a database page with two OS pages, two disk sectors, and two filesystem blocks simplified I/O and reduced fragmentation. Modern hardware still benefits from this alignment, even though SSDs now use 4 KB sectors. Competing systems such as Oracle and SQL Server also default to 8 KB, while analytical engines like DuckDB favor much larger blocks to maximize sequential throughput.

Inside each page, a 24‑byte header holds critical metadata: the Log Sequence Number for crash recovery, an optional checksum, and flags that indicate visibility and space status. Following the header, a slotted array of 4‑byte line pointers maps logical tuple locations, allowing PostgreSQL to move tuple data without breaking index references. Tuple data grows upward from the page’s bottom, while line pointers grow downward, leaving a free‑space gap between the pd_lower and pd_upper offsets. This layout enables lightweight page‑level pruning, HOT updates, and efficient index‑only scans, all observable through the built‑in pageinspect extension.

For practitioners, the page architecture directly influences capacity planning and performance tuning. Roughly 8 KB minus header space yields about 8 168 usable bytes, translating to around 100‑120 average rows per page for typical schemas. Knowing the free‑space gap helps anticipate page splits and autovacuum activity. While PostgreSQL supports alternative block sizes (1‑32 KB) at compile time, the operational cost of rebuilding clusters outweighs marginal gains, making the default 8 KB the sensible choice for most workloads. Understanding these internals empowers DBAs to diagnose storage anomalies, configure effective WAL and checkpoint settings, and leverage index‑only scans for read‑heavy applications.