Engineering

Multi-tenancy

Multi-tenancy is an architecture where a single instance of a software application serves multiple customers ('tenants'), with each tenant's data logically isolated from others — sharing the same infrastructure but with strict separation.

In depth

The alternative is single-tenancy: each customer gets their own dedicated infrastructure. Single-tenancy is used by enterprises with compliance requirements (separate databases, separate servers). Multi-tenancy is the norm for SaaS — more cost-efficient and operationally simpler.

Three approaches to multi-tenant data isolation:

1. Row-Level Security (RLS): all tenants share the same tables, filtered by a tenant_id column with database-level security policies. Most common for SaaS built on PostgreSQL/Supabase.

2. Schema-per-tenant: each tenant gets its own database schema (set of tables) within a shared database. Better isolation, more complex migrations.

3. Database-per-tenant: each tenant gets their own database. Maximum isolation, highest cost, used only in enterprise/compliance scenarios.

For most SaaS MVPs: RLS on PostgreSQL (via Supabase) is the right choice. It's secure, scalable, and simpler to operate than schema or database separation.

Real example

Notion uses multi-tenancy — millions of teams (tenants) share the same infrastructure. Your workspace's pages, databases, and members are isolated from every other workspace at the database level via row-level security and tenant IDs.

Related terms

Ready to build your product?

Fixed price. 21-day delivery. Senior team.

Get a free scoping call →

Browse the glossary