Any xtdb love?

[magnus0re]

I watched Workshop video: A deep dive into XTDB with Jeremy Taylor (2021-12-02)
And then, I was interested so I went through the fun tutorial.

Has anybody here used it for projects?

[mvarela]

I’m using it at work (have been using it since last year). It’s very nice and “comfortable” to work with. The Datalog dialect it uses is a bit different than Datomic’s, and the fact that it’s document-oriented also gives a different feel. There are some rough edges sometimes, but overall, I’m pleased with it. Also, the guys at Juxt (and especially @refset ) have been super helpful and responsive.

[jacobobryant]

I use it in my bootstrapped startup, and also in Biff, a web framework I made. (The startup’s built on Biff). Biff is due for an update; hopefully that’ll happen… sometime. Very happy with XTDB.

[magnus0re]

Cool that several have used it for projects, even though it is a quite new db.

[jan]

We’ve been experimenting with it in Spacy, with a Postgres for the log and document storage. Very happy with it so far. We’re still trying to figure out the best way to structure our documents in order to avoid conflicts upon concurrent writes.

[magnus0re]

Concurrency can get ugly indeed. My naïve assumption would just be that the xtdb transaction log makes it easier to deal with, and the ‘winner’ of a concurrent write is just which ever happens to be last in system time…

[jan]

Precisely. That works like a charm if you store a history of domain events as separate documents. Naively saving the current state of your entire entity comes at a risk of losing some writes though. So far ::xt/match has helped us enforce consistency, but we’re curious if there’s a better approach.

[jacobobryant]

Have you looked at transaction functions? I use matches + retries on match failure myself, with the idea that I can always switch to transaction functions if I have any writes that start having a lot of contention.

[jan]

Do you mean using a transaction function that would behave like clojure.core/compare-and-set! and replace the document only if no concurrent writes took place? No, I haven’t considered it; thanks for the hint!

[mvarela]

Yes, pretty much… Pretty much all update logic should live in transaction functions, at least that’s how I’ve been using it, and I haven’t had problems with race conditions (other than a bug in the kafka backend, which was promptly fixed by the JUXT guys pretty much as soon as I reported it).

[jacobobryant]

replace the document only if no concurrent writes took place?

That sounds more like using match; for transaction functions, they get evaluated sequentially at index time, so there aren’t any concurrent writes to compete with.