Multi-tenancy is the single most consequential architecture decision a SaaS team makes. Get it right and you scale predictably; get it wrong and you carry the bill for years.
Pattern A — Shared schema, row-level security
Best for most consumer and SMB SaaS. Cheap, easy to operate, fast to onboard tenants. Requires disciplined RLS, careful index design, and a sharp eye on noisy neighbours.
Pattern B — Schema-per-tenant
Best for mid-market and enterprise where customers want clearer isolation but you still want a single database fleet. Migrations get harder — you’re running them N times. Tooling matters.
Pattern C — Database-per-tenant
Best for regulated industries, sovereign-data deployments, and enterprises with strict data-residency requirements. Operating cost goes up; isolation goes way up.
The decision matrix
- How sensitive is the data?
- How big does a single tenant get?
- Do tenants demand data residency?
- How often will you run schema migrations?
- How quickly do you need to onboard a new tenant?
Shared schema with RLS for v1. Schema-per-tenant for enterprise plans. Database-per-tenant on demand — with clean upgrade paths between them.
