What is Columnar Storage?

The Core Problem: Traditional row oriented databases store data the way you think about it: one complete record after another. When you fetch a user profile with 50 fields, reading one row makes sense. But modern analytics queries have a completely different pattern. They scan billions of rows yet only need 5 columns out of 300, and they almost always aggregate the results. Imagine a query that calculates average order value across 1 billion orders. The query needs just two columns: order_id and total_amount. But your orders table has 80 columns. With row storage, you must read all 80 columns for every single row, even though you discard 78 of them immediately. At terabyte scale, this wasted I/O becomes catastrophic. How Columnar Storage Works: Columnar storage reorganizes data physically on disk. Instead of storing [row 1: all columns], [row 2: all columns], it stores [column A: all rows], [column B: all rows]. When your query needs only 5 columns, the database reads only those 5 column files. This is called column pruning, and it can reduce I/O by 50 to 100 times for wide tables. But the benefits go deeper. Because all values in a column have the same data type and often similar patterns, compression becomes incredibly effective. Techniques like dictionary encoding and run length encoding can shrink data by 5 to 20 times. A column of repeated country codes compresses beautifully. A column mixing random data types does not. The Key Insight: Columnar storage trades write complexity for read performance. Writing a single row requires touching multiple column files instead of appending to one place. But for analytics workloads where each query scans millions of rows and you run far more reads than writes, this tradeoff delivers 10 to 50 times better performance.