I dont agree with the premise that running transactional and analytical workloads on the same database is architecturally “simpler”. In my experience this is only true at very low scale and those contexts are already sufficiently well served by existing database tech.
At a certain amount of scale its net “simpler” if the analytics people are free to do their jobs without worrying they will bring down “the app” and vice versa.
OLAP has certainly become overcomplicated but collapsing everything into big monolith dbs again is an over correction IMO.
Yeah, that’s interesting. I think both SingleStoreDB and Rockset have come up with solutions to this problem (by separating the compute). But I understand that most database providers do not have a mechanism for the analytics people to not bring down the app accidentally.
To be fair, the OP is part of PingCap, who build TiKV/TiDB, which is built from the ground up to support both workloads, they call their database “Hybrid Transactional Analytical” database, which is explicitly designed to support both workloads without either side “treading on each other”, and without needing ETL pipelines gluing stuff together.
