If the system can run without indexes while still being performant in other areas ( multiuser oltp for example ) then that's awesome, absolutely. Pretty much ev

If the system can run without indexes while still being performant in other areas ( multiuser oltp for example ) then that's awesome, absolutely. Pretty much every other trick for faster multi-record queries sacrifices oltp performance in some way. But to step back a bit. DBA's manage database engines as much as they manage the data, often more. Schema design, index maintenance etc is part of it, but on a stable system often only a small part. And replacing those db engines is a big deal, as per my earlier comments about compatability and integration - without big, strategic management support, it's often effectively impossible to change them. So you're offering a choice that, in my experience at least, DBA's actually rarely make - coders, architects and history usually make, or made those choices. We also often don't care about the data "as information", only in the sense that it's been entrusted to our care. The people who use the data usually wear different hats (bi, ml, analyst, data science, sometimes managers and of course coders ). But those people aren't adding / removing indexes in DBA managed environments. Your parallel column scan sounds cool, and I can see how it falls naturally from your design, and it's often hard to retro fit onto an older engine. My instances have 11000+ clients during peak, we've already turned off almost all capabilities for parallel queries - because for 95% of the workload it cant help, and likewise an errant query that suddenly jumped up and started consuming multiple cores worth resources could be a disaster. So it sounds like you've got some cool stuff, you're just talking to the wrong demographic!