This expands on my previous post.
Problem Statement
Random Access Memory is still an expensive resource in computer systems. At least cloud providers charge a lot for it (Google Cloud between $2.50 and $3.00 per month per 1 GB RAM). If you start your software business, you probably only need one server. Our use case is that we want to run one VM (or container) per customer for a SaaS business with several thousands of customers. Running a transactor, peer-server, and your app with the peer library on a single VM consumes more memory than necessary. You have the memory overhead of the three JVMs, and each has its own Datomic object cache, memory index, etc. Datomic-Local helps for these use cases but lacks the powerful entity API.
Solution Proposal
Offering the Datomic transactor and peer-server as a library would allow to run everything in a single JVM. The transactor, peer-server, and peer-library could share the same Datomic caches. The datomic.api and datomic.client.api could stay the same, meaning you still need to connect to the corresponding Datomic ports on localhost. Later, the ports could be bound to a network interface to allow additional Datomic peers to connect to this main server (for example, if you start a VM or container just for a single batch job). If you need to upscale your system, you can take apart the initial setup to have separate VMs for the transactors and peer-servers. At the same time, the Datomic peers can still use the same API, so you don’t need to change your application code.