datomic

Ovi Stoica 2025-06-19T07:05:35.122679Z

Is it better to have a datomic-peer separate from your Clojure app and connect to it via datomic.client.api, or run the peer as part of your app? Until now, I just ran the peer as part of my app, but I found this repo: https://github.com/galuque/datomic-compose?tab=readme-ov-file, where the peer is separate. I assume this makes it a bit more fault tolerant if you have more clients connect to the same peer. What is the general consensus around this, regarding datomic pro? For context, the scenario is that the transactor, peer, and eventual client run on the same VM or under the same VPC

đź‘€ 1
Noah McMillan 2025-09-21T07:53:36.497719Z

@ovidiu.stoica1094 how did you end up deploying datomic? I personally feel like peer is simpler. It defintely has a confusing deployment story for a hobby programmer.

Ovi Stoica 2025-09-21T09:14:09.162859Z

I ended up having the peer as part of the app. It makes the data feel more local. I’m on mobile now but I’ll post more details when I’m at PC I didn’t experience any issues so far

👍 1
Ovi Stoica 2025-10-14T06:35:19.901069Z

@noahmjohnstone, sorry, I just saw your follow-up question. Actually, I have them on the same server for now, as I don’t have a lot of load, but it would be fairly simple to move things to a setup like you described. The current setup is: Peer as part of my app, transactor, and PSQL storage on the same VM I own

👍 1
Ovi Stoica 2025-06-19T07:28:40.112659Z

From a bit of research, I think 1 advantage in fault tolerance is that if your client app crashes, once you restart, the peer’s cache is still intact.

Ovi Stoica 2025-06-19T07:30:47.275099Z

I see references to this link but it is broken now: https://docs.datomic.com/on-prem/clients-and-peers.html

favila 2025-06-19T13:59:51.835089Z

If your application runtime has or wants restrictions that make running it as a peer uncomfortable or impossible, client can allow that app to keep using datomic

favila 2025-06-19T14:01:09.248749Z

Peers need: lots of ram and cpu, fast access to storage, lots of deps to support peer runtime. Clients don’t

favila 2025-06-19T14:02:19.649769Z

But peers offer horizontal scalability that coincides exactly with your app: vast majority of what an app does is often talk to db

favila 2025-06-19T14:02:51.991929Z

(But if not true for your app, maybe client a better fit)

Joe Lane 2025-06-19T16:36:09.622859Z

FWIW, I'm not sure I agree w/ the statement "lots of ram and CPU" @favila. You can run a peer with as little as 64m ObjectCache (if you want).

favila 2025-06-19T17:06:35.203989Z

Lots relative to an equivalent client, which needs no OC, no startup, etc. I wouldn’t run a peer in an aws lambda (let’s say) because of constraints on that runtime

đź’Ż 1
favila 2025-06-19T17:12:30.121009Z

I don’t mean to imply client should be your first choice. Like I said, peers give you horizontal scalability aligned with your app deployments, but to leverage them well you will have fewer, larger processes with count changing less frequently. This is not the usual way a web app is scaled with eg a sql backend, where you may have lots of transient, relatively lightweight and stateless processes

favila 2025-06-19T17:13:03.427169Z

Client can give you an arch that looks more like that if you need it

Ovi Stoica 2025-06-20T06:19:15.344379Z

Thank you for your thoughtful responses, everyone! I’ll go with a peer as part of the backend app and see from there

👍 1
Noah McMillan 2025-09-22T09:42:51.453119Z

@ovidiu.stoica1094 Nice, how many servers did you use to deploy it? Server for app JVM + Peer lib, one for transactor (with a standby), and one for storage?