Issue-015:-Pages, heaps & row storage anatomy
Every Postgres read and write moves exactly one 8,192-byte unit between disk and memory — regardless of how small the row you’re looking for. Understanding this changes how you think about schema design, index decisions, and every query you write.
A senior engineer I work with discovered something that permanently changed how they designed schemas. They were profiling a slow endpoint and found the database was reading 14,000 pages to serve a query returning 200 rows. Each page is 8KB. That is 112MB of I/O for a 200-row result.
The table had 47 columns. The query selected 3 of them. But since row storage puts all columns of a row on the same page, reading those 3 columns forced Postgres to load every page containing the 200 matching rows — each page packed with all 47 columns of all rows on that page.
The fix was a covering index. But understanding why the covering index helped — and why the original query was expensive — required understanding what a page actually is.
The 8KB page: Postgres’s atomic storage unit
Postgres never reads or writes individual rows. It reads and writes pages — fixed-size blocks of 8,192 bytes (8KB). Every heap table, every index, every system catalog is a sequence of these pages. When you execute SELECT * FROM employees WHERE id = 42, Postgres locates the page containing that row and loads the entire 8KB page into shared_buffers, even if the row itself is only 200 bytes.
This is the page size contract: the operating system’s unit of I/O aligns with Postgres’s page size, meaning each read maps to one or a small number of OS operations. Making pages smaller would mean more I/O operations for sequential scans; making them larger would waste memory for small tables. 8KB is the default, compiled-in constant.
