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.

[yangzhaox]

@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

[Pramuspl]

+1. Multi-tenant auth is a must-have. I've been looking for info a couple of days until I reached this thread.

I'd be great if you had some kind of a general roadmap, like Remix project does for example.

[KieranFleckney]

1+

[potential701]

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]

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

If you are going to promote your book you should write on the page what type of technique the multi tenancy is using.

I wouldn't pay for any book that tells me to put tentant_id column on every row.

[activenode]

Hey, author here (thanks for tagging).

I wouldn't pay for any book that tells me to put tentant_id column on every row.
I'm happy to help you if the book is for you but I'm not sure what you would expect. There are pretty much 3 ways of doing multi-tenancy.

1. Separate DB (which is basically separate Supabase project). No-brainer, can also be automated, although I wouldn't want to spin up a new DB for each client - but really depends on what you want.
2. Same DB but different schema -> "just" adapt the schema in the initiated Supabase client. There are a few other things to manage though given that the built-in mailing would need to be adapted which is why I don't recommend using the built-in mailing in my book when using multi-tenancy
3. Same schema but proper DB architecture, same as in No2 it applies you want to separate E-Mails etc. as well and this is what's done in the book and yes, this requires also (not just) adding logically the tenant id to the rows.

Scrolling up I now see that @steve-chavez already gave that similiar answer in the beginning so I mine are just adding a bit more context here.

So question remains: What do you expect to see? @Zyles

I can't elaborate the whole book but let me tell you there's certainly so much more than just "adding a tenant id". E.g. optimizing the RLS accordingly, emptying the built-in templates so abusive use (forcing to use the built-in one instead of the custom one) is avoided, etc. . The book has 500+ pages so it's really hard to give a summary here

[barbinbrad]

I'd like to do 2, but I have to do 3, because even though the client supports schemas, I haven't figured out how to tackle migrations. Ideally I'd have one set of migrations that'd fan out to multiple schemas.

[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.

[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