Fork me on GitHub
#datomic
<
2021-04-19
>
jamesmintram09:04:30

Hey all. I asked a little while back about doing multi-tenant apps with datomic and a couple of ideas came up. One of those was using a single DB per customer. So the connection string might look like : "datomic:" This looks interesting - do this mean that all databases backed by the same Postgres instance (for example) share the same DB? In which case, the only different between: "datomic:" and "datomic:" Is some sort of partioning key that Datomic uses to keep data separate within it's backing store?

jaret13:04:34

Hi, For on-prem we generally recommend that you run a single logical database per transactor (pair). Some customers use additional DBs for operational tasks, but generally a datomic on-prem system (and license) includes a transactor pair, single DB, associated peer applications. Perhaps we can discuss your needs for separate DBs. Have you evaluated https://docs.datomic.com/cloud/whatis/architecture.html? Cloud is more suitable for per db mutli tenancy. How many DBs do you envision long term? What are the sizes of each DB that you expect? If you'd like to share more details you can shoot a ticket to <mailto:[email protected]|[email protected]> and/or we can arrange a call to discuss.

jamesmintram09:04:06

If that is the case, then is it feasable to "open" a new DB connection per http request? or keep a pool of conns in some sort of LRU cache? From the docs

Datomic connections do not adhere to an acquire/use/release
pattern. They are thread-safe and long lived. Connections are
cached such that calling datomic.api/connect multiple times with
the same database value will return the same connection object.

prnc12:04:53
replied to a thread:

Even if there is no filter fn as such I would be interested how you should go about restriction user access (say only to “their own” data) in e.g. queries? I’m just new and not sure what the right approach is 😉 Is it just “do it in every query explicitly” kind of thing?