Several comments mention the data immutability of Datomic as a plus and I just wanted to say you can totally make a plain-old-RDBMS table append-only and get those benefits. I'm sure this is commonly done.

I did it with a timestamp on the tables that was captured at insert time. All reads were against views of the tables that were defined such that the only tuples returned were the "most recent" tuples by appropriate data fields and max(timestamp). "Deleted" records were just indicated by a flag.

This preserved the ability see the full history for a tuple from creation, all mutations, all the way to deletion. This scaled reasonable well up to low millions of tuples on a normal, single database server. But it was for an internal project, so the number of clients hammering at it was quite low.

Datomic (as presented in this video) seems like a great thing. But if it's so great, why are so few people talking about it? Is it because it only exists for Clojure, and few people know or talk about Clojure?

I love Clojure as a language, and I have wanted to use it in production; but there are so few opportunities other than solo building - where you really have to climb a steep wall due to the Clojurist mentality of /Frameworks Bad! Choose all your own libraries good!/. Instead I have found myself happy and productive in the Elixir/BEAM world, of course initially because of Phoenix.

And like many people, I have just been accepting the destructive, non-historic approach to data management with typical RDBMSs. If there were a Datomic for Elixir, I'd probably use it.

Must Datomic (or a data management approach like it) be tightly coupled with Clojure?

Relevant blog I found interesting: (Datalevin)

https://yyhh.org/blog/2024/09/competing-for-the-job-with-a-t...

From the perspective of someone not familiar with the topic. And I touches on performance

Statistically (and from experience) I'm probably the weird one here, but I cannot fathom why Datomic isn't more popular.

I get that postgres is a good default in many cases, and I don't expect SQL to die tomorrow. But there are _so many_ apps (most/all backoffice apps I've worked on for example) with 10s or 100s of transactions per second at most, that would love to have the data available directly inside your business logic, and where both business logic and devops would improve by many orders of magnitude by having a full transaction log of all changes done to your data over time.

Is it _just_ because Datomic is different and people don't get it, and that preconceived notions makes you think Datomic is something it isn't?

Here's to the crazy ones!

I didn't get the part about running the queries against the production database. How exactly was it not overloading the database?

And the point he makes about storage capacity seems off; it's often the cost of db storage that's the problem. Why would I pay to store data I'll never need?

Does Datomic have similar features to TerminusDB? I've heard about Datomic before but never took the time to dive in.