XT currently does provide something that few - if any - other databases do. a sweet spot between a document database, with bitemporality, and graph traversal.
@xlfe I’m forking this bit from the SSaC thread (hope that’s okay). I’m curious which aspects of XT’s design and behaviour are most important to you? We often run into folks who are happy to have a sane document store, true bitemporal queries, or graph traversal … but it’s rare to hear someone champion all three at once.
Put another way: if you weren’t using XTDB, is there a contender that closely approximates the features you need most?
This is an open question to the crowd, obviously. We’d love to know what you want/need out of a database in 2022.
We migrated from datomic, and at first the document vs entity differences seemed significant, but in hindsight any loss of fidelity from not having a (very strong) schema has been easily outweighed by the fact that xtdb open source, and therefore, inspectable and extendable.
I have spent much time browsing the source to understand how xtdb works, and am using two modules of my own (vector search using ngt as a secondary index and the avisi datastore module). none of that is possible in (eg datomic), or it would be more work to acheive with higher fragility (ie bolting on separate systems).
Aside from that, which features are most important? hard to say, but off the top of my head these three really stand out
(almost) covering indexes - important for arbitrary graph traversal
the ability to perform pulls on documents (we don’t use much datalog but make extensive use of pull expressions)
to a lesser extent, immutability / bitemporality (nice to have but we could probably get away with out it for our use case).
If xtdb didn’t exist, well. We’d probably be on datomic or postgres! But neither of these approximate both the features xtdb offers and it’s openness/extensibility. Datomic has the best coverage of features (but is not open or extensible) and postgres, while open, lacks much of what makes datomic and xtdb great (clojure!).
