Multitenancy with a single database and multiple profiles

[MaticDiba]

We are trying to use ACA-Py with multitenancy enabled (using Askar with Postgres for storage). The current implementation of multitenancy is limiting for our use case because it creates a new database for each tenant agent. This is problematic with a growing number of possible tenants.

We need a solution where each tenant wallet could be stored in the same database. One approach would be to enable storing tenant wallets to single multi-tenant sub wallet (separate database from main base wallet) as separate Profiles. With this approach, mapping to each tenant would be done similarly to the current approach - with the base wallet. But instead of creating a new database for each tenant, we would just use one "tenant sub wallet" with multiple profiles. And then profile id can be used to map to the correct tenant.

Askar library already supports creating multiple profiles in one database. Is there an item on the road map or proposed solution to enable this approach in Aca-Py as well?

Any suggestion/discussion would be much appreciated.

[swcurran]

@andrewwhitehead , @TimoGlastra -- any comments on this? I know this has been discussed. Did we get to the start of a design for this? Andrew -- pretty sure we talked about this when we were in Utah at the last Connect-a-thon :-).

Did Kiva do something like this and could that design be leveraged?

[bartekus]

My recommendation here would be to have a look at https://postgrest.org and also https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/ for the specifics about achieving multi-tenancy that has scalability as well as security as their main objectives.

By externalizing the data layer to a easily manageable API interface and relying on Postgres row-level access control, it's entirely possible to facilitate a proper access for a administrative organization to each wallet that it manages but also enable each individual holder ability to access their data with minimal overhead and development cost.

Has anyone thus far considered this approach? If yes, what downsides have been determined, if no, how could I be of service in terms of presenting this as viable option for others to consider/use?