The latest articles on DEV Community by Jishnu Saha (@jishnusaha89). https://dev.to/jishnusaha89 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4080245%2F40bff0f7-05c0-492d-8f4a-caf42c039967.jpg https://dev.to/jishnusaha89 en Jishnu Saha Thu, 20 Aug 2026 10:00:32 +0000 https://dev.to/jishnusaha89/how-does-a-database-actually-store-your-data-17f1 https://dev.to/jishnusaha89/how-does-a-database-actually-store-your-data-17f1 <p>Every backend engineer has run SELECT * FROM users WHERE id = 42 a thousand times.<br> Most assume the database goes and grabs exactly that one row.<br> But it doesn't. It can't.<br> Disks read in fixed-size blocks, not single rows — so databases define their own unit for this: a page. Every read pulls the whole page, then selects the row from it.<br> That one fact explains a lot — why deleted rows don't vanish immediately, why a table's file is bigger than its raw data, why "no index" means scanning every single page, and why an index actually works (it's just a sorted shortcut to a page + slot).<br> I wrote a deep dive on pages, slotted pages, heap files, and full table scans — the physical layer underneath every SQL query: <a href="https://jishnusaha.me/blog/database/how-db-store-data" rel="noopener noreferrer">https://jishnusaha.me/blog/database/how-db-store-data</a></p> database postgres databaseinternals