Row vs column storage

The biggest physical difference between typical OLTP and OLAP databases is how they lay data out on disk. (It's a tendency, not a rule: some OLTP systems store columns, and some engines do both.)

Row-oriented

A row store keeps each record's values together:

text

(101, Aman,  Delhi,  25000)

(102, Riya,  Mumbai, 18000)

(103, Kabir, Pune,   32000)

Fetching customer 102 means reading one place on disk and getting every field at once. That suits point lookups, small updates, frequent inserts and transactions that need a whole record.

Column-oriented

A column store keeps each column's values together:

text

customer_id: [101, 102, 103]

name:        [Aman, Riya, Kabir]

city:        [Delhi, Mumbai, Pune]

balance:     [25000, 18000, 32000]

Now take an analytical query:

sql

SELECT AVG(balance) FROM customers;

A column store reads just the balance values and skips the rest. A row store has to read every field of every row to find them.

Column storage gives analytics four wins:

Column pruning: read only the columns the query names.
Compression: values in one column are similar. A city column with a few hundred distinct values over millions of rows can be stored as small codes, so far fewer bytes come off disk.
Vectorized execution: the engine processes batches of values from one column in tight CPU loops instead of one row at a time.
Cheap scans: large reads don't pay for columns nobody asked for.

Which is faster?

There's no universal winner. Compare a 10-column table:

Query	Row store reads	Column store reads
`AVG(balance)` over 100 million rows	All 10 columns of every row	1 column
Everything about customer 102	One row, in one place	10 separate columns, one value each
`SELECT *` over the whole table	Everything	Everything (pruning saves nothing)

Reading or changing a few records across many columns: row storage tends to win.