// Practical guide
Multi-tenant isolation in SaaS
The incident B2B customers fear most
Leaking one customer’s data to another is the worst kind of B2B SaaS failure: it breaks trust in a way that is hard to recover and usually becomes a contract clause. And it is easy to introduce when the product grows fast and one query forgets the tenant scope.
Multi-tenant isolation is not a feature; it is an invariant that must hold on every read and write.
Where isolation leaks
The hole is rarely global; it is usually one route that forgot the filter.
- A query that filters by resource id but not by the user’s tenant.
- A new endpoint that copied another and inherited the missing scope.
- A cache or search that mixes results across tenants.
- A background job that runs without the correct tenant context.
How to guarantee it
Make tenant scope hard to forget. Instead of trusting every dev to remember the filter, enforce it in the data layer — with a composite key, a default ORM scope, or Row-Level Security in the database.
- Composite key (tenant_id + id) on sensitive tables.
- A default ORM/repository scope applied to every query by default.
- Row-Level Security (RLS) in Postgres as a safety net in the database.
- An automated test that attempts cross-tenant access and expects denial.
When to ask for human review
If you cannot confidently state that every route carries the tenant scope, this is a classic Risk Review case: a short human read of 1 to 3 flows to say whether isolation holds or needs deeper testing before a B2B sale.
Frequently asked questions
Is database RLS enough on its own?
It is a strong safety net, but the ideal is layered defense: application scope + database RLS. RLS catches what the application forgets, and the application avoids depending on the database alone.
How do I test isolation without breaking production?
Create two test tenants and try, with one’s session, to read and write the other’s resources. An automated test expecting denial on cross-tenant access becomes a permanent regression guard.
Does it apply to small SaaS too?
It applies from the second customer on. Introducing isolation early is cheap; leaking data between customers is expensive and hard to reverse.