Row-Oriented Storage

When you run INSERT INTO users (name, email, age) VALUES ('Alice', 'alice@email.com', 30), the database needs to physically write those bytes to disk. Here is something most developers never think about: the order in which those bytes are arranged on disk has enormous consequences for performance.

Imagine a library. You could organize books by shelf, each shelf holds one complete book, all pages together. Or you could organize by page number: page 1 of every book on the first shelf, page 2 of every book on the second shelf.

Sounds absurd for a library, right? But databases actually make this choice. Row-oriented storage is the "complete book per shelf" approach. Every column of a single row is stored together, contiguously, on disk.

This is how PostgreSQL, MySQL, Oracle, and SQL Server store data by default. It is the traditional model, and for many workloads, it is exactly right.

In a row-oriented database, each row is stored as a single contiguous block of bytes on disk. When you have a table like this:

The data on disk looks roughly like this:

[1, "Alice", "alice@email.com", 30] [2, "Bob", "bob@email.com", 25] [3, "Carol", "carol@email.com", 35]

All columns for row 1 are next to each other. All columns for row 2 are next to each other. And so on.

Why does this matter? Because of how disks work. When you read data from disk (especially spinning HDDs, but even SSDs to a degree), reading contiguous bytes is dramatically faster than jumping around. This is called sequential I/O vs random I/O.

So when you fetch a complete row (SELECT * FROM users WHERE id = 1), the database reads one contiguous chunk and has everything it needs. Fast. Efficient. One disk seek.

But when you want just one column across many rows (SELECT AVG(age) FROM users), the database has to read every complete row, extract just the age field, and throw away everything else. It is reading names and emails it does not need, wasting I/O bandwidth.