The general consensus as I understand it is: column-oriented indices/storage options are good for OLAP, large scale analytics, bulk data analysis. Row-oriented indices are suited more for OLTP, individual "record processing."
Both are just techniques and there's nothing stopping a single db product from offering both.
Again comes back to usage patterns. Yes, if you're doing aggregation operations on a small number of columns then I expect locality of reference could be better with a column-store, rather than thrashing through row-retrievals one after another (and then just throwing them away after aggregating).
But if you're frequently doing "look up this customer and others like them" and then using the bulk of the information there? I'd expect better cache behaviour out of row oriented storage.
But these days it's so unclear what's happening inside the actual "black box" that is our hardware that it's hard to make generalizations.
The general consensus as I understand it is: column-oriented indices/storage options are good for OLAP, large scale analytics, bulk data analysis. Row-oriented indices are suited more for OLTP, individual "record processing."
Both are just techniques and there's nothing stopping a single db product from offering both.