To be fair, column storage isn't just engineering around the peculiarities of disks (although that's the biggest part of it). Columnar storage offers large ben

To be fair, column storage isn't just engineering around the peculiarities of disks (although that's the biggest part of it). Columnar storage offers large benefits in compressability and when working with wide tables. In a wide table/row oriented environment you end up bringing a bunch of data in to memory that is totally irrelevant to your problem, which has a bunch of negative consequences: particularly poor data locality, which dramatically slows the processing of the data (kills cache prefetching, and poor utilisation of cache lines can lead to your L1/L2 cache getting nuked). If you're making use of a page cache, row oriented systems offer poor utilisation here, too. - additionally, this guy has the impression this implementation might be "easy"; that is, a lot less work to do compared to writing a traditional rdbms from scratch I think he's oversimplifying dramatically. A vast amount of the code in, say, postgres is dedicated to query processing/planning, transaction maintenance, etc. That's not going away or getting any simpler with SSDs. Writing the storage engine is certainly a big job, and yes, SSDs will be more forgiving to unintelligently written engines, but DBMSs aren't really going to get a great deal easier to implement.