How a table is laid out on disk decides which kinds of queries are fast.
Row and columnar layouts hold exactly the same data, arranged in opposite ways.
Choosing the right one can make queries many times faster.
Row storage writes each record's values side by side, so reading 1 whole order is a single read.
That suits transactional systems, such as a shop's order database, which handle many small reads and writes.
Columnar storage writes all the values of one column side by side, then the next column, and so on.
That suits analytical queries, which scan many rows but touch only a few columns.
Similar values sit together, so compression such as storing repeated values once works very well.
Run-length encoding, for example, stores 1,000 identical country values as one value and a count.
Many columnar engines also process a block of column values at once, much like vectorised NumPy code.
Writing or updating a single row is slower in columnar storage, because its values are spread across many places.
That is why operational databases stay row-oriented and warehouses go columnar.
Some databases offer both layouts, keeping recent data in rows and older data in columns.
In practice, analysts benefit most by selecting only the columns they need, which columnar storage rewards.
The usual mistake is writing SELECT * on a wide columnar table, which throws away the main advantage.