Replies: 2 comments
-
The recommended option with OpenFGA for separating tenants would be to use separate stores for each which allows for their models and tuples to be separate but using the same database backend. You will generally want to use a separate database for your app and for OpenFGA anyway. Rather than using a different database for each tenant you would create a new store for each and scale the database cluster you tie OpenFGA with. |
Beta Was this translation helpful? Give feedback.
-
Thanks @ryanpq. Stores are what I was seeing as the current option here, but that lacks a lot of the flexibility my use case requires. That solution provides worse data isolation, makes the data less easily portable, and complicates server-specific separation use cases (like geo-colocation of data). I hope that the team will consider allowing the server to support multiple back DBs to give users more flexibility in their architecture in the future. |
Beta Was this translation helpful? Give feedback.
-
We're building a multi-tenant SaaS solution and following the general pattern of DB/schema per tenant. For my application DBs this is easy, but I have not found a way to do this effectively with OpenFGA short of a deployment for every tenant.
We also can't implement this at the
pgbouncer
level because the connection string is always identical.Is there an established way of handling this common architecture pattern?
Beta Was this translation helpful? Give feedback.
All reactions