Clojurians Log v2
datomic 2026-09-05
I’ve used datomic some, but many of you here will have more experience. Also curious about your experience with other history DBs. What was the primary use case for history? Did you primarily use the history for operational stuff? I mean to answer questions like “How did the db get into this [undesirable] state?” Did you use history much for domain stuff? For example, answering questions like “What was the state of this quote at each stage of the sales cycle.” For something like that, would you query the db and just find the tx in history when the sales cycle stage changed and see the state of the quote as of that transaction? Or would you still model that and take “snapshots” of the quote entity at each stage change of the sales cycle? Or when the domain needs provenance, would you attach that data to the transaction entity or model it separately? I guess I am trying to understand what people have experienced as the benefit of history and whether it eliminates a whole lot of domain modeling or not. My sense right now from my experience in the past is that the operational component is the more valuable one, but wanted to hear other people’s experiences.
we have our own content formats. we have a data-driven, extensible CMS for those formats (thanks Clojure), and part of that toolset is a generic, schema-driven change-log, which is pretty must just a browser over d/history. this saves all sorts of 'oh @#$%' and headscratching over and over (and over) for our business!
I would say that the history should only be used almost exclusively for operational uses. If you use Datomic history for domain time, you must be very sure that the only way to cause changes to your domain data is through your system and Datomic's transactor. Because you cannot manipulate Datomic's history in any way. If you learned today that actually, account A's status as of five days ago was X, you cannot fix the Datomic history to represent that.
yep. we accepted this very early on. this system has been in continuous use since 2013!
I wanted that to not be true so hard, I had to learn it a few times 😅
> If you learned today that actually, account A's status as of five days ago was X, you cannot fix the Datomic history to represent that. > Sounds like the schema is missing a data field for the date that the thing was true according to another source of truth. No?
I've goofed up our database a couple of times after a botched data migration... Datomic history was indispensable for figuring out what went wrong and how to fix the problem
An other problem with using history to model domain time is that if you decide to change your data model and write a migration, you don't (usually) migrate the past. So the API exposing the history should handle every version of the data model.
We use history and transaction metadata to provide a strong audit trail. I can't count the number of times that history/metadata has allowed us to understand where bugs are hiding, what went wrong with, e.g. migrations and even to identify developers mistakes running transactions at the REPL (a reality that seems all to common in our business right now). The only place we expose txInstant in a UI is where it is related to an "system" entity that represents a transactional outbox. IOW, not really a domain concept.