I am not sure how this would work in a production database but the problem of concurrent reads and writes are pretty well solved in Clojure. https://clojure.org/reference/refs
I was also wondering if the Datomic approach is better.
I was also wondering if the Datomic approach is better.
There's a reason why Datomic is generally known as being quite slow, and Cognitect being really insistent on not allowing anyone to publish any benchmarks, ever.
(As a sidenote, I'm a long term Clojure developer and an absolute fan of Datomic's data model, but the context of the original article is all about speed)
I guess Datomic might be slow, I was more referring to the idea of using a transactor to manage the concurrent writes as opposed to the model the was proposed in the video. Splitting up your database to different parts makes sense to me.
https://www.nikolasgoebel.com/2018/09/13/incremental-datalog...
Also, a recent video from ClojureConj on the subject:
They partly solve the 'no one can tune this black box' with their cloud offering by doing it for you, but cloud is a different product and dependent on AWS, it doesn't have an on-premise version.
[1] https://news.ycombinator.com/item?id=15726376
[2] http://www.dustingetz.com/:datomic-facebook-tao/
Neither of these architectures resemble the relational model anymore. They resemble a half-baked bug-ridden implementation of half of Datomic.
TLDR: Nobody likes their database and zero teams at scale run vanilla out-of-box database.
This might shed light on what people mean when they are talking about tuning Datomic: http://www.dustingetz.com/:datomic-performance-gaare/ I'm sure there is more but this is the only thing I have ever come across.