I imagine that some of the choices to lean into the RDBMS specifics also come from application architectures and data complexities. If you have a few large mon

I imagine that some of the choices to lean into the RDBMS specifics also come from application architectures and data complexities. If you have a few large monolithic applications that share multiple schemas (so no single-owner), and you then need to do classic OLAP, OLTP and cubing, you're essentially stuck with database solutions from the same era. Same goes for record-oriented software and mainframes or low level rtos software that requires real mode. The requirements never stand on their own (which is pretty much what you wrote anyway ;-) If a BI solution can do gRPC to a few specific services that contain the datasources for the dimensions you need, then nearly all OLAP-native features are irrelevant. It also means that the dynamic resource usage means that your overall cost in terms of energy and money are significantly lower. The big 'if' in all of those is going to be 'does the organisation have the skills and the willpower', and often the answer is no. Because hiring some MSP to do your BI, data management and have some single vendor do your ERP, EHRM, ESB on top of some RDBMS "sounds" good and means it's their responsibility, and when a user then sends them a support ticket about how crappy their UX is and how much the workflow sucks, they will get ignored and somewhere in some expensive place, old grey men shake hands on yet another successful quarter ;-)