Document multitenancy technique via tenant column (with RLS)

[voroninp]

Type of issue

Other (describe below)

Description

I would not call it an issue at all, but I'd suggest if possible, extending the documentation with an explicit statement, that in most cases tenant column should exist in every table containing multitenant data (case of single database).

There are multiple reasons for it:

• Enabled Row Level Security on DB side. (unfortunately, you do not mention this db feature)
• Tenant is a natural shard key for the table + it should be the first component of almost any index.
• Can define a simple global filter that does not require navigation properties to the entities which hold reference to the tenant. (that is no joins)
• Easy to introduce an interceptor to check that modified entities belong to the active tenant.

Why do I ask for this? Well, I believe recommendation from EF team will have more weight than my words.

Page URL

https://learn.microsoft.com/en-us/ef/core/miscellaneous/multitenancy

Content source URL

https://github.com/dotnet/EntityFramework.Docs/blob/main/entity-framework/core/miscellaneous/multitenancy.md

Document Version Independent Id

bb29a2b6-c401-287f-2da9-1aeb3c633b41

Article author

@JeremyLikness

[roji]

@voroninp I agree that our multitenancy docs could certainly use various improvements. Hoewver, I do not think it's our place to recommend a particular multitenancy techniques - different things work for different scenarios. For example, row-level security capabilities differ from database to database (your link above is for SQL Server), and might not be appropriate on a given database for tenancy isolation; and even if so, in some scenarios database separation may be mandated for various reasons. In addition, in some multitenancy scenarios there's a need to have (hopefully small) schema changes across the tenants, in which case a tenant column doesn't work (and different schemas/databases need to be used). There really isn't just one recommended technique here.

I do believe we should document the different options more extensively though; putting this on the backlog.

[voroninp]

@roji , thanks.

Just to clarify.
I was asking more details for the section about single shared database, so every argument was exclusively about this approach.

But if you add more guidance to other approaches it's even better.