Is there a use case where RDBMS is the best data store for querying only? I am trying to figure out whether there is any legitimate use case for Relational Data Store (like MySQL, PostgreSQL, etc) in DDD, Event sourcing and its projections. Hear me out.

In event sourcing your OLTP and write side is solved for you. For OLAP and the whole read/query side, you are free to create a projection - store data from the source of truth in a way that will fit your query use case the best way possible. So that the read is extremely fast. Therefore I am trying to figure out, if I am only to query the data store, is there a use case, that I would want to store in RDBMS/Relational Data Store? I see that for any use case there is a better Data Store than Relational.


Do you need to get one item by ID? - key-value Data store is the best
Do you need some nested structures to query? - Document Data store is the best
Do you want to query relations between structures? - Graph Data store is the best
Do you want to do some analytical processing? Aggregations, averages and what not? - Column Data store is the best.


Is my thinking correct? Do you see any flaws? Read use cases that RDBMS solves the best?
I find your question a bit confusing, as you mix different concept domains togeter.

RDBMS stands for "Relational database management system". If your data model is relational in nature, you use an RDBMS to store, process and query it. How it optimizes these things physically is an implementation detail (your "Column Data store" is one example).

If your data model is strictly non-relational, you might choose a different DBMS, such as key-value store type, whose implementation is more optimized for the corresponding use cases.