postgresql is just one option to store the tx log and docs… so it isn’t a case of using “relational database as a triple store”

Thank you, but I meant: what's the architectural difference that makes working with a triple store performant in datomic/xtdb?

@UA7E6DU04 I'm not sure about the XTDB implementation but Datalog as a query language makes a big difference for querying the data with as many predicates as you want. From the book Designing Data Intensive Applications: (the example is in Cypher but it's the same idea)

There are probably many specifics to XTDB/Datomic/something else, but afaict it’s the different covering indexes (EAV, AEV) that make datalog queries performant… and one of the reasons we can do it is storage space being cheap and fast these days

and having a SQL table like create table triples (e bigint, a text, v text) would be cumbersome to work with even if you had indexed it by every combination

> having a SQL table like create table triples (e bigint, a text, v text) would be cumbersome to work with even if you had indexed it by every combination This is the correct answer IMO. Most OLTP ("OnLine Transaction Processing") relational databases typically use a row-oriented storage model, which strongly couples the physical data layout to the logical data model. Attempting to use sparse and wide rows is inefficient in these systems (e.g. NULLs takes up space, and excess I/O for a full row when you only need a couple of columns), and running lots of joins is typically also inefficient/problematic. By contrast, systems like Datomic and XT encourage performing lots of joins over sparse indexes because it can make complex modelling a lot simpler.