What is a database page?
storage fundamentals.
a page is a fixed-size block, often 8KB, holding multiple rows; databases read and write whole pages because disk and OS I/O are block-oriented, amortizing seek cost and matching the buffer pool unit.
What's really being asked
The interviewer checks foundational knowledge of how databases sit on top of block storage and why they batch I/O into pages.
The full answer
A page, sometimes called a block, is a fixed-size chunk of storage, commonly 8KB in PostgreSQL or 16KB in InnoDB, that holds many rows along with a page header and a slot directory mapping row identifiers to offsets. It is the smallest unit the database reads from or writes to disk and the unit it caches in the buffer pool. Databases use pages because the underlying media and operating system are block-oriented: a disk seek and rotation, or an SSD program operation, carries a large fixed cost regardless of how few bytes you want, so reading a single 200-byte row would waste almost all of that I/O. By transferring a whole page, the database amortizes that cost across many rows and benefits from spatial locality, since related rows often sit together. Pages also give a clean unit for the buffer manager, locking, checksums, and write-ahead logging. Fixed size keeps free-space management and addressing simple.
The mistakes people make
Believing each row is read or written individually. Confusing a page with a row or a table. Thinking page size is arbitrary rather than tuned to media and memory. Ignoring that pages are also the caching and recovery unit.
What usually comes next
What is inside a page header; how does the buffer pool cache pages; what happens when a row exceeds a page; why is page size a tuning knob.
A concrete example
To read one customer row, the engine asks the buffer pool for the 8KB page containing it. If absent, it issues a single page-sized read from disk, then serves that and neighboring rows on the same page from memory. A later query for an adjacent customer needs no I/O at all because the page is already cached.
Interview question
Why do databases read and write whole pages rather than individual rows directly to disk?
- a.Pages prevent SQL injection at the storage layer
- b.Rows are too large to write one at a time
- c.Writing rows individually would violate ACID by definition
- d.Block-oriented I/O has a high fixed cost per operation, so whole pages amortize it across many rowsCorrect
Why? this is the answer
Each disk or SSD operation carries a large fixed cost no matter how few bytes are moved, so transferring a whole page spreads that cost over many rows. The other options misstate row sizes and conflate storage with security or ACID.
Just read this? Test yourself on what you have been reading.
Read the original → postgresql.org
- #databases
- #storage
- #page
- #buffer-pool
- #io
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on databases — each one lists the topics its interview covers.
See open roles