A comment that I just wrote up on r/Clojure in response to “What would you choose [XTDB or Datomic]? When and why?”:
My gut feeling is:
-
If you’re a solo developer: XT
-
If you want tight AWS integration: Datomic
-
If you know bitemporality will be useful for you: XT
-
Otherwise, it might not matter. They’re both good products. Maybe talk to the respective XT/Datomic teams about your use case if you’re unsure.
As a solo developer, I used Datomic (peer at first, then cloud + ions) for a year and change, then switched to XT which is what I’ve been using for all my projects for the past 3 years. The main reasons I switched were ease of operation and licensing/cost. The latter’s not a problem with Datomic any more, but I still love that with XT I can use Postgres as a storage backend and that I don’t have to run a separate transactor process. (For dev, both support local filesystem storage.)
Other stuff:
-
The documents-vs-datoms difference has been a moot point for me in practice. They both get the job done. The main/only downside I’ve run into is that on XT you have to roll your own solution for updating/upserting documents without clobbering concurrent transactions that touch the same document. I might release a standalone lib for that soonish.
-
I like that XT is schemaless (or as I think of it, “bring your own schema”) so that I can roll my own validation logic with Malli, which is more compact than Datomic’s schema format. Of course it’s just data either way; you can write helper fns to make either one more ergonomic. I also like that I don’t need to insert my schema into the database for it to take effect. (Mainly a benefit for the solo developer use case probably.)
-
XT’s data model/transaction format has fewer parts and is quicker to learn.
-
Both have exciting futures, with XT v2 in the works and Datomic being backed by Nubank.
Disclosure: JUXT sponsors my open source work. Go JUXT! Go JUXT!