In row oriented DBs data is laid out row by row. In order to read a column of data the DB has to read through the entire row to get to the next one. When comput

In row oriented DBs data is laid out row by row. In order to read a column of data the DB has to read through the entire row to get to the next one. When computing an analytical query like the sum of a single column, the DB wastes cycles skipping through all the columns in the row. In columnar databases a batch of column data is stored sequentially followed by the next column and so on. So if you need to sum a column you can read it sequentially very quickly and sum it up without needing to touch the data of any other column. Columnar is also better at filtering and grouping for similar reasons. As a general rule if your workload looks like “select sum(x) where y group by X” a columnar db will be a great fit. The trade off is that columnar databases don’t like being updated and work best when you only insert data. This is because when you update existing data you now need to rewrite several pages on disk because the columns are all over the place. Because of this there’s very few areas where a pure columnar DB makes sense. They’re great for timeseries metrics like sensor data , click event logs etc. places where you are just recording a fact and don’t need to update past events.