Multi-Tenancy Patterns

Multi-tenancy exists on a spectrum from fully shared (all tenants in one table) to fully isolated (each tenant has their own database server). The right model depends on your tenant count, tenant size variance, compliance requirements, and operational maturity.

The three primary models:

Shared database, row-level security (RLS): all tenants in the same tables, with a tenant_id column on every table. A PostgreSQL RLS policy filters rows automatically based on the current session's tenant context. Cost: minimal: one database for all tenants. Isolation: logical only: one slow query from tenant A can starve tenant B (noisy neighbor). Used by: small-to-medium SaaS startups with hundreds to thousands of tenants.

Schema-per-tenant: each tenant gets a dedicated PostgreSQL schema (e.g., tenant_acme.users, tenant_globex.users). Physical isolation within one database instance. Migrations apply across all schemas. Cost: one database, moderate operational complexity. Isolation: better I/O isolation through separate table files; no data leakage possible due to missing tenant_id filter. Used by: Shopify, Basecamp for small-to-medium tenant counts.

Database-per-tenant: each tenant is a separate PostgreSQL instance (or at least separate database cluster). Full isolation: separate connections, separate disk I/O, separate CPU. Compliance-friendly (GDPR right-to-erasure is a DROP DATABASE). Cost: high: each tenant requires provisioned compute and storage. Used by: enterprise SaaS with large tenants, strict data residency requirements.

Key Takeaways

• →Shared DB + RLS: minimal cost, logical isolation only: noisy neighbor is a real risk
• →Schema-per-tenant: file-level isolation, no data leakage, but migrations touch all schemas
• →Database-per-tenant: full isolation and compliance-friendly, but operationally expensive at scale