A profoundly important observation. Yes, using a limited set of physical structures simplifies the code and, in some cases, streamlines execution. But that's pu

A profoundly important observation. Yes, using a limited set of physical structures simplifies the code and, in some cases, streamlines execution. But that's putting lipstick on a pig. With a handful of exceptions, database architectures were set in stone in the mid-1980s in Wisconsin. Which is ridiculous. The machines that they were designed to optimize don't even exist any more. Take simple storage tier-ing as an example. Why don't infrequently accessed column values migrate to slower cheaper storage automatically? Sure, databases have concepts of tablespaces and partitions, but those are WAY too coarse grained for today's environments. And there are more than 100 issues like this. In short order, NVMe SSD will be ubiquitous, with 3Dxpoint on the horizon. The data structures that make sense for spinning disk are just not equally optimal for the performance characteristics of SSD, Ram, and cache. Regarding your point about reads and writes on the same store, you might take a look at the new "HTAP" systems (hybrid transactional and analytic). The VectorWise guy has a "new" (probably old by now) project called HyPer