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.

afaict, there is no similar functionality in cloud

In our system we only check the authorization (i.e. access) at the borders of the system. When you're passed that interceptor/layer we don't bother. That way the queries are simpler and faster (at the cost of always running one (or more) queries beforehand.

Queries are data and compose, programmatically building queries is a normal thing to do :)

Good example at the 12 minute mark of how Nubank controls ownership and authorization w/ their schema using rules. https://youtu.be/7lm3K8zVOdY

I’ve started drafting an impl of what I need with rules—will definitely check out the nubank talk as is seems to go that direction. Thanks everyone!

we too have authorization rules at the boundary, all commands and queries from clients are authorized… I think it’s common that authorization is based on a few core entities that are part of the query args / command payload

that nubank presentation with filter was interesting, it would be to see actual performance numbers… it would seem to me that the filter approach can’t use indexes efficiently, but don’t know any details

Thanks @U11SJ6Q0K! Being new to datomic this is quite an interesting problem for me. The filter solution (on-prem only!) seems to be very clean, and it’s what nubank are using. Query logic is separated from access restrictions. Leveraging “database as a value” and thus playing to datomic strengths. The other nice thing about datomic is ofc “queries are data” as mentioned by @U0CJ19XAM I’ve just used this approach to write a boundary query-as-a-user fn, which rewrites the queries to refer to access restriction rule. Somehow it doesn’t really feel right, less separate, less explicit. Maybe it’s just my shoddy impl 😜 We will see how it fares in practice! If anyone has examples of those kinds of things in real world (w/ users, permissions, auth etc) open source code I would love to see them! Cheers!

How complex is your permission model?

ATM I’m only concerned with the ~trivial case of: “Alice owns some resources and only Alice can see them” where resources are entity level, so not very complicated and not very granular, but that will probably evolve. It’s a knowledge base type of application so where this will potentially get more interesting is in the cross-sections of public and private information--private knowledge graphs embedded in public ones. So I’m just trying to model this in a nice way with datomic without prior experience with datomic ;) Presently I was mainly concerned with the simple mechanics i.e. where those restrictions should sit (in terms of best practices), so it’s not error prone. So today I’ve just added a rule and a centralised query fn for restricted resources that just adds those access constraints captured by the rule to the :where clause... so far so good I think ;)