What is multi-tenancy?
Most SaaS products are multi-tenant. The whole design rests on one promise: no customer ever sees another's data.
In short
Multi-tenancy is a software design in which one running application and its database serve many customers, called tenants, while each tenant sees only its own data. It is how most SaaS products work, and it depends on every query being scoped to the right tenant.
Also called: Multi-tenant architecture, Tenant isolation
When does missing tenant isolation turn into a data leak?
The day a second customer signs up. A prototype usually has one tenant: you. After that, every query that forgot to filter by tenant becomes a leak, and it will not show in testing, because each tester only looks at their own account. Our article on users seeing each other's data shows how that surfaces in Lovable apps.
What are the main multi-tenancy models?
Microsoft's architecture guide treats isolation as a spectrum rather than a yes or no. At one end every tenant shares everything; at the other each has its own deployment. Most products sit between, and the choice is commercial as well as technical, because shared infrastructure is cheaper and dedicated infrastructure isolates better.
| Model | What is shared | Main trade-off |
|---|---|---|
| Fully multitenant | Everything: app, database, network | Cheapest; one bad change or heavy tenant affects all |
| Horizontally partitioned | The app tier; each tenant has its own database | Limits noisy neighbours; more to deploy and manage |
| Vertically partitioned | Most tenants share; some get dedicated infrastructure | Code must support both; some cost recovered |
| Single-tenant deployments | Nothing | Strongest isolation; cost grows with every tenant |
A noisy neighbour is a tenant whose heavy use slows the others. For a young SaaS built on Supabase, the fully shared model is the usual starting point, which puts all the weight on isolation inside one database.
Where should multi-tenancy isolation be enforced?
In one place that every query passes through, never in a filter each developer or each prompt has to remember. AWS's guidance for SaaS on PostgreSQL says row-level security is required for tenant isolation in a shared database, because it moves enforcement into the database itself.
- In the database, with row-level security policies on every table.
- In one application layer that adds the tenant to every query.
Either can be right. What matters is that there is one enforced rule, and a test that tries to cross the wall.
How do you enforce tenant isolation in a Supabase app?
Give every tenant-owned table a tenant column, turn on row-level security everywhere, and write policies that compare that column with the signed-in user's teams. Then index the column, keep the service role key on the server, and prove it holds by signing in as one tenant and reading another's rows:
- Give every tenant-owned table a tenant column, such as team_id, and enable row-level security on every table in an exposed schema, as Supabase's guide says.
- Write policies that compare that column with the signed-in user's teams. Supabase's example reads team ids from the user's token; it warns a token is not always current, so removing someone from a team may wait until their token refreshes.
- Index the tenant column, because every policy filters on it.
- Keep the secret service role key on the server only: it bypasses row-level security entirely.
- Test it: sign in as tenant A and try to read tenant B's rows.
Our RLS policy examples show the policies in full. If a live app has already leaked across tenants, that is urgent work for a vibe coding rescue.
Common questions
Is multi-tenant less secure than single-tenant?
Not inherently. It concentrates the risk in one place, isolation, so that one place has to be enforced and tested rather than assumed. In practice: one rule, in the database or one shared layer, and a test that signs in as one tenant and tries to read another's data.
Should each customer get their own database?
Usually not at first. Microsoft's guide notes that dedicated infrastructure isolates best but its cost grows with every tenant, while shared infrastructure is cheaper. Some products move only their largest or most regulated customers onto their own deployment later, which the guide calls vertical partitioning.
What is a noisy neighbour in a multi-tenant app?
A tenant whose heavy use slows everyone else on shared infrastructure, for example by running large queries against the shared database. Giving tenants separate databases limits the effect, as Microsoft's guide describes, and rate limits per tenant help in a fully shared design, so one customer cannot use up capacity.
How do you test tenant isolation?
Create two tenants with their own data, sign in as one, and try to read, change and delete the other's rows through every route and API the app exposes. Microsoft's guide recommends testing for leaks between tenants whatever model you choose. Automate it to run on every change.
Go deeper
Supabase RLS policy examples and mistakesSupabase RLS policy examples for owner, team, public, admin and storage access, with a test for each and common mistakes that break or open your tables.
Related terms
Read next
Sources
- Microsoft Azure Architecture Center: Tenancy models for a multitenant solution
- AWS Prescriptive Guidance: Row-level security recommendations for multi-tenant SaaS on PostgreSQL
- Supabase documentation: Row Level Security
Sources checked October 24, 2026
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
