What is multi-tenancy in auth?

Multi-tenancy, in SaaS, means one application instance serves multiple customer organizations (tenants) — each with their own users, data, and settings — while keeping everything isolated.

Why it matters for auth

Multi-tenant auth has to answer:

• Which tenant does this sign-in belong to?
• Can a user belong to multiple tenants?
• What role does a user have within a specific tenant?
• Can tenant A’s users ever see tenant B’s data?

Getting this wrong means cross-tenant data leaks — a security bug that can end customer relationships.

The basic schema

tenants(id, name, ...)
users(id, email, ...)              -- global
memberships(tenant_id, user_id, role)  -- user is in tenant with role
posts(id, tenant_id, ...)          -- tenant-scoped data

Every tenant-scoped query filters by tenant_id. Users can belong to multiple tenants with different roles.

Enforcement

Two layers:

1. Application code: every query includes a tenant filter
2. Database: Postgres row-level security enforces the filter even if a query forgets

The second layer is defense in depth. It catches the bug that the first layer missed.

Build it from day one

Retrofitting multi-tenancy onto a single-tenant schema is a months-long migration with a permanent tail of “did we catch them all?” bugs. Architect for it from day one — the upfront cost is negligible, the retrofit cost is immense.

See the full auth glossary for related terms.