Crux was a pretty straightforward choice. Didn't really consider any non-datalog DBs. I've used Datomic quite a bit, but preferred crux since it's open source, has filesystem persistence and doesn't require a separate process for the transactor (nothing wrong with Datomic's choices; the tradeoffs just make it unsuitable for Biff). I went with crux over datahike since it's more mature and has postgres persistence (and Kafka persistence, not that I need that yet). I haven't actually used the bihemporality features of crux yet, but maybe they'll come in handy.
That makes sense to me. I've been trying to decide out of Crux or Datahike for a side project. I was leaning towards Datahike because I didn't like the idea of having to do a full document update like you do in Crux, but I need to dig into it a bit more.
Are you concerned about that for performance reasons or for ease-of-use reasons? To address the latter, I made a separate transaction format for Biff that allows merging (it's similar to Firebase's transaction format). So e.g.
[[:crux.tx/put (merge (crux/entity db #uuid "some-user-uuid")
{:username "foo"})]]
There is a race condition though; if another tx updated that document after the crux/entity call but before `:username "foo"` was written, then that tx would get clobbered. I'm planning to add `:crux.tx/match` operations automatically to prevent that from happening. There was talk on #crux in Clojurians slack today of using the newly-added transaction function feature to do merges. Haven't looked into that myself.
Just for ease-of-use. In Datomic/Datahike you can update a single datom/fact. I'll have to look into making some similar sort of helpers for what you've done.