Database / Supabase Intermediate to Advanced Interview Questions
What is the difference between schema-per-tenant and RLS-based multi-tenancy?
Schema-per-tenant gives each customer their own Postgres schema (or even database), with identical table structures duplicated per tenant; isolation is structural — a query simply cannot reach another tenant's schema unless explicitly told to.
| Schema-per-tenant | RLS-based (shared schema) |
| Strong structural isolation | Isolation enforced by policy, not structure |
| Migrations must run per schema | One migration applies to all tenants |
| Scales poorly past many tenants | Scales well to thousands of tenants |
RLS-based multi-tenancy instead keeps every tenant's rows in the same shared tables, distinguished by a tenant_id column, and relies on a policy like tenant_id = current_tenant() to enforce isolation. It's the more common Supabase pattern because a single migration updates every tenant at once and it scales to far more tenants than provisioning a schema per customer would allow, at the cost of isolation being a policy you must get right rather than a structural guarantee.
What enforces tenant isolation in an RLS-based multi-tenant design?
Why does RLS-based multi-tenancy scale better to thousands of tenants than schema-per-tenant?
More Related questions...
