Multi-tenant

[arsewizz]

is there a way to create a database with the possibility of Multi-tenant ?

[steve-chavez]

This depends on how you'd like to structure your database. Basically, there are three ways:

1. Separate dbs for each tenant
2. Same db but separate schemas for each tenant
3. Same db and same schema, tenants separated by RLS policies

(Check this article for knowing the types of multitenancy.)

I think 3 would be the most straightforward way for now(2 may be possible later). You could have a tenant_id and base your RLS policies on that, check this AWS blog post for more details on how to do it.

Option 1 seems bad for scalability. Since a connection is tied to a database, if you have many tenants you'll need to maintain a lot of connections(and in postgres this is bad because 1 connection = 1 process).

---

There was a previous discussion on: #957 (reply in thread)

[kangmingtay]

hey @elhe26, yeah you're right, we currently don't support multi-tenancy on the auth schema due to the UNIQUE constraint on the email column.

[yzx396]

@kangmingtay is there any plan to add support of mult-tenancy on the auth schema?

[ausmurp]

Any multi-tenant app I've used still has the unique email constraint. Think about Slack, you can sign in with your personal email, and see all of your workspaces. The architecture for this is simple, you just have the following schema:

accounts, account_roles, and a account_users (account_id, user_id, account_role_id).

Then you require account_id (tenant_id, or whatever you want to call it) as a header for every request.

[elhe26]

@ausmurp The issue here is that the password may be different and if we use RLS + Auth Table the user won't be able to "sign up" since he already exists on Auth.

For example, take Firebase Auth. As of this moment, this is the best multi-tenancy implementation I've seen so far. Easy to implement and deploy, you don't have to worry about multiple tables. You use the tenantId and the client can be subscribed to that tenant without any issues. If the client goes to a different tenant, the same procedure is implemented.

@kangmingtay Do you have any plans on how to tackle this implementation? If so, where can I follow this?

Edit:

Just following up on @yangzhaox's question.

[baderdean]

Hello,

in multi-tenancy we could have multiple levels: organization and users. The same users could belong to many organization. So many possible logins, one with Social Login for his NGO, one with his email address for his Gym, another with email address (the same one) for his children's School.

regards

[Zyles]

We need multi tenancy with one DB per customer.

Are there plans to add this?

[kangmingtay]

Hi everyone, we do plan to make gotrue multi-tenant eventually but we don't have a clear timeline for this yet. The upstream version of gotrue from netlify supports multi-tenancy using method (3) described by steve above: Same db and same schema, tenants separated by instance_id. However, we would prefer to either go with (1) or (2) and this would require quite a significant architectural change and not something we would like to rush into. Ideally, we would also want to dogfood it on our platform first before releasing it to the rest of the projects on Supabase!

[ADO]

I suspect this second approach of Same DB, different Schema (with a shared structure within those schemas in most use-cases) would not only have substantial security and import/export benefits by effectively siloing company/tenant data by schema but could potentially be a game-changer for realtime performance and improve scaling.

• For multi-tenant scenarios (e.g. company-level tenant accounts with multiple users who may potentially belong to other company/tenant accounts), queries are often company-wide data shared between users, i.e. merely restricted to the tenant. Think "public within the scope of the company"
• Within a tenant's own schema it would mean no extra RLS policies on those tables would be needed
• And you still have RLS if needed for "private to the user even within the scope of the company" anyway

Having different schemas per tenant would allow more (automatically scoped by schema) table-wide non-RLS subscriptions for realtime (faster), so

• socket.channel('realtime:public:table_here:tenant_id=tenant_id_here') becomes:
• socket.channel('realtime:tenant_schema:table_here')

Even the RLS subscriptions and subscriptions to filtered data should be way faster with the schema scoping.

I believe this could also dramatically reduce the RLS performance hit seen as subscribers grow... as it would be restricted to the scope of an individual schema/tenant's subscribers so that changes to one tenant's data don't require looking up the effects on every subscriber system-wide.

[victorsoliveira]

@kangmingtay

How can i write in instances table and reference instance_id at users table ? I didnt found how to in flutter client api for example.

Thanks!

[kangmingtay]

you can't right now because multi-tenancy is not supported on supabase auth yet - we don't plan to use the instances table too and we are going to be deprecating it

[victorsoliveira]

Ok @kangmingtay! Thanks for the information.

[barbinbrad]

If we set a header manually in the supabase-js client (a tenant id), is there any way to access to from RLS?

[btelles]

Great to hear that this has been considered. My vote would be for Option 1 above for the following reasons:

• Tenants may be hesitant to upgrade to the latest backend services, and any breaking changes in APIs would be unwelcome.
• Billing on a per-tenant basis would be slightly easier.

[rubenbase]

Hey team! Any place where we can track the multi-tenancy implementation process?

[bwinkers]

Option 1 would allow me to provision my tenants into DBs and the client could provision their sub-tenants in schemas. All while keeping data in smaller packages that are easier to move, backup and restore.

[rchrdnsh]

Any updates that can be shared on this subject? Would love to know :-)

[ghost]

For Option 1, separate db per tenant - Could you just use the new Management API to create a new project for each tenant and then deploy to it?

I was thinking of trying something like that and then I would just have to figure out how to let users switch between organizations if they belong to multiple orgs. One "low rent" way I thought of for doing this: generate a magic link for the org they want to switch to and navigate them to it.

I think this solution would require:

• A central project for orchestrating your SaaS concerns, tracking which tenant owns which Supabase project, etc.
• A separate domain/subdomain per tenant frontend OR carefully controlled creation of supabase-js clients.
• A way for each tenant frontend to safely ask for the list of other tenants a user belongs to and switch to them. (Could let each tenant frontend talk to the central SaaS project, but we don't want to do it so we can figure this out on the backend by letting tenant Edge functions use supabase-js to work with the central project with a service key.)

To be clear: Tenants would not own their Supabase projects in any way as developers or have any control over them such as rolling out their own Edge functions. They're just users.

[Sun3]

I am also interested in Multi-tenant...

[peacocc]

Hi. I am trying to build a multi tenancy platform and have run into the issues outlined above. After trying Next-Auth, which only has a single email call back location, I was hoping that supabase would at least allow me to programatically change the siteUrl property via the Management API so I can send the email confirmation to a custom tenant domain. Is there any news from the Supabase team on whether a solution will be provided on any of the options above?

[elhe26]

Is there any updates to this request?

This request along with transaction support are the only things stopping our company from phasing out firebase completely.

[wixys]

Hi everyone, any updates about Multi-tenant feature? 👀

[liesahead]

Tough choice, but I made it in favor of firebase because of the multitenancy.

[mosnicholas]

+1 this would be helpful :)

[sebastianbachmann]

Not really sure, but is this new Supavisor thing going in the right direction? https://github.com/supabase/supavisor

[viktorsmakreckis]

plus one

[rsbichkar]

+1

[siddiqss]

+1

[Bych]

+1

[reedwane]

+1

[Mihai-github]

+1

[josecaputo]

Hello @kangmingtay

Do you have any update or eta about this feature to share with us?

It would be awesome to have this as a built-in solution as I have no code experience and it seems a bit complicated and confusing to me to implement what was suggested for schemas.

Appreciate your attention

[josecaputo]

Hi @FlexiFarmAdmin,

Your solution seems to be what I am looking for however I have no code experience and I was wondering if you could send me a quote to prepare a step-by-step guide so I can implement same solution in supabase/schemas to manage my companies data's.

Thank you very much

[wandersonalwes]

+1

[minimalknave127]

+1

[coheedev]

+1

[slavakurilyak]

Check out supa.guide by @activenode which shows you how to build a multi-tenant platform

[Zyles]

Different schema per tenant is the minimum acceptable solution.

Also different database per tenant depending on what type of information you're storing (regulations).

[activenode]

Also different database per tenant depending on what type of information you're storing (regulations).

That's the definition of "new Supabase project for each client" so that's already available and you can automate it with the API: https://supabase.com/docs/reference/api/v1-create-a-project

Different schema per tenant is the minimum acceptable solution.
Given that your database has different extensions who will also live in different schemas as well as given the auth schema is its own schema apart from "tenant" schemas, I'm not seeing how "the minimum acceptable solution" provides any security benefit as it really does not.

I can pretty much pull up a visionary glass ball and state: You will never see this implemented in Supabase and I also don't know of any competitor who does that this way. I certainly will you not recommend my book since you are already primed into a direction that I find hard to find consensus with but there's still the little hope in me that reading it would maybe change your mind about the necessity of schema separation.

Tldr: Schema separation does not necessarily provide any added security benefit as both can implement role-based security by all means. So all that remains is my understanding that you want it to simply go to a schema and only see specific tenant data there without the need to filter, that I could kinda understand. But in this case you're best of using the "Create new project" API around your infrastructure.

[ammelto]

What about when different tenants have slightly different table structures? I'm working on an application that has a ton of customization for each tenant, some even include properties in data models which might be entirely unique to that tenant. In our case, security and separation are important but so is the ability to provide a high degree of flexibility on the underlying data structures on similarly names tables.

[FlexiFarmAdmin]

@ammelto different table structures would have to be separate database or at least schemas. For separate schemas you can achieve that as above - which is what we are using in our beta atm (even though each client currently has the same structure that won't necessarily continue like that forever so it's flexible)

[ammelto]

@FlexiFarmAdmin Oh wow this is fantastic! I must have missed your post when skimming through the comments here. This is exactly what I was looking for, thanks!

[rajivkr]

Is there any update on this? We have multiple users who use a variety of login methods across tenants, like google for tenant 1, github for tenant 2 etc. So, ideally we should allow users to signup with any means across tenants.

[activenode]

For real, if you not only share database structure but different configurations, there is no other answer than pulling up a Supabase project for each client and building your automation around it with stuff like proper seeds and migration files (hint: https://www.youtube.com/watch?v=nyX_EygplXQ) .

Project Platform API: https://supabase.com/docs/reference/api/v1-create-a-project

If it's "only" about the different Login, that can be easily solved with an added identity_to_tenant table and then forwarding properly.

[RickVM]

Would be awesome to have the option to dynamically set the 'from' email when sending authentication emails. We have a multi-tenant setup going with supabase auth, but are restricted to sending our sign in emails from 1 address though we'd like to change the domain based on the organization/domain that is active.

[activenode]

Use the Auth Email Hook, that's the best practice! https://supabase.com/docs/guides/auth/auth-hooks/send-email-hook?queryGroups=language&language=sql

Full flexibility, usable with Edge Functions as well.

Cheers, activeno.de

[RickVM]

Awesome, seems like exactly what I need. Thanks! @activenode

[rh-id]

I think it is possible currently. Using http server like nginx to route request based on apikey header. So you have a list of apikey mapped to supabase instances.

It is not one schema one tenant but one supabase instance one tenant

[benkissi]

Can something be learnt from this https://neon.com/docs/guides/multitenancy ?

[RepairYourTech]

The problem is supabase and postgres itself is not meant to be miltitenant.

Thankfully lots of nice new databases are evolving now, like SurrealDB