Having only read the abstract: Am I correct assuming this could be used as the core piece of implementing something like Datomic?

I have been thinking a bit about how amazingly useful a generic, distributed B-Tree would be, thanks to it's applicability with immutable data structures.

Datomic has a very simple concurrency model that makes a sophisticated distributed B-tree like this unnecessary. Minuet carefully manages concurrent access to the data, through snapshots and keeping track of read/write data access per transaction to manage concurrency according to the desired isolated level. Datomic has scalable read-only views, but a serial write transaction executor, so the distribution aspect is fairly simple.

On Minuet, while I do like the area of work, I think it is a mistake to keep track of read and write sets for concurrency control. The performance is not great when you want to do real-time analytical queries. Check Figure 17, where you can see that the throughput barely increases when adding machines for frequent snapshots.

Thanks for clearing that up, makes a lot of sense to me. I too would prefer the single transactor model.

I think the MVCC features in Minuet are applicable in instances where immutability can be used as an optimization, such as Datomic. However, Datomic has a very specific data model and set of use cases which means they likely optimize in a variety of domain specific ways. More likely I would suspect Minuet is positioned to be the basis for a RDBMS storage engine, or on its own as a powerful key/value store.

> means they likely optimize in a variety of domain specific ways

How I wish they did.

I've never used Datomic, so maybe this should have been written as:

> which means they _could_ optimize in a variety of domain specific ways.

Could you elaborate on that?