this might be better asked in #datomic or https://ask.datomic.com, although the first question might be - what does "partially persistent" mean? I'm not familiar with that being a term that Datomic uses to describe itself.

Thanks, I'll post there Alex. I found it while reading this PDF - http://www.bioinf.uni-leipzig.de/conference-registration/13haskell/submissions/hal8_submission_17.pdf > Fully persistent data structures are the most common type used in functional programming > languages. On the other hand Datomic is currently only partially persistent because one can only > modify the newest version [1]. > Which seems to make sense with what I've read, IE while you can query the history of facts using time, you cannot modify these past versions, only modify the present one.

sounds like not a great fit for a database

What is the definition of "modify" in the context of immutable data structures? :thinking_face:

I think in terms of datomic, it'd be like transacting against history - creating some additional history branch off of that.

> sounds like not a great fit for a database Agreed, was just hoping perhaps the compromises / trade-offs were discussed at some point in a talk perhaps

just off the top of my head it just sounds like a mess. There would be no real idea of what the "present" is, since at any time you could walk back (along any branch) to any arbitrary transaction point and add a new branch. If a database is designed to allow you to keep a single point of truth for data stored across multiple applications, making it branch in time breaks that.

I think it makes sense, since that is what git does. I just think it isn't something a lot of people need, and adds complexity, so why bother?

During tests, a branchable db is helpful. This can be done in memory using https://github.com/vvvvalvalval/datomock "Branching of reality" can be accomplished by things like tagging transactions, like this video from Tim Ewald on reified transactions: https://docs.datomic.com/on-prem/learning/videos.html#reified-transactions Otherwise, checkout bitemporality, like XTDB has: https://docs.xtdb.com/concepts/bitemporality/