Multi-tenancy
Sharing one deployment among many customers (tenants) to cut cost, with isolation between them. Models range from shared-everything (cheapest, weakest isolation) to siloed (strongest, priciest). The core economic lever of SaaS.
- SaaS serving many customers with similar needs.
- Cost-efficient scaling.
- Customers requiring strict isolation/compliance (silo them).
- Very few, very large customers (dedicated).
Definition
Multi-tenancy serves multiple customers from shared infrastructure. Models: shared DB + shared app (pool, cheapest), shared app + per-tenant DB/schema (bridge), and siloed stacks per tenant (strongest isolation). Tenant ID scopes all data.
Why it exists
Dedicated infrastructure per customer is expensive. Sharing amortizes cost across tenants, making SaaS economically viable. The tradeoff is isolation vs efficiency.
How it works
Every row carries a tenant_id; every query filters by it. Resource limits (quotas, rate limits) prevent noisy neighbors. Larger/regulated tenants get siloed deployments. Migration between models is hard, so choose early.
Scaling limits
Noisy neighbors (one tenant's load degrading others), data leakage if tenant scoping is missed, and per-tenant limits that are hard to enforce fairly. Schema migrations affect all tenants.
Cost shape
Shared models are far cheaper per tenant. Blow-ups: a single huge tenant dominating shared resources and over-siloing small tenants.
Alternatives
- Single-tenant deployments — Strong isolation, high cost.
- Hybrid (silo large tenants) — Balances cost and isolation.
Failure modes
- Tenant data leakage from missing filters.
- Noisy neighbors.
- Migration pain between models.