Welcome! Please see the About page for a little more info on how this works.

0 votes
in On-Prem by

At scale you definitely want a separate transactor, but for development or for deploying an early prototype , it would be very handy to be able to have the transactor running in the same process as the peer. This would trade reliability and predictability for resource efficiency, and allow deploying on an inexpensive instance somewhere in a public cloud. This would probably lower the bar for trying out datomic in many settings.

In fact, it seems that datomic local allows having an embedded H2 database and a transactor into the same JVM process as your client.

You mentioned that it is possible to do the same for datomic on-prem, could you detail how one might do it?

1 Answer

0 votes

Hi @Chpill. The peer library can act in standalone mode, using an in-memory database as a stand-in for the other components. A memory DB is in the same process as your peer:


`(def db-uri "datomic:mem://hello")`

It will not persist and is entirely in memory, but seems like what you are after for development purposes. Otherwise, as you have alluded we recommend process isolation per the design: https://docs.datomic.com/pro/operation/deployment.html?search=isolation#process-isolation?