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.

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?

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

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!

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?