SaaS Multi-Tenancy Decision Guide
Shared, separate or hybrid: choosing a tenancy model you will not regret at 10x.
The three models
| Model | How it works | Isolation | Cost and ops | Choose when |
|---|---|---|---|---|
| Pooled | Shared database and schema; every row carries a tenant id. | Logical, enforced in code | Cheapest, one thing to run | Many small tenants, self-serve SaaS |
| Bridge | Shared database, one schema or collection set per tenant. | Stronger, still shared hardware | Moderate; migrations run per tenant | Mid-market tenants with custom needs |
| Silo | A separate database (or stack) per tenant. | Strongest | Highest; automation is mandatory | Enterprise, regulated or data-residency deals |
Questions that decide it
- Do contracts require data residency or physical isolation?
- Will one tenant ever be big enough to slow the others down?
- Do tenants need custom fields or workflows?
- Can your team automate migrations across many databases?
- How will you price: does isolation earn a higher tier?
Rules that apply to every model
- Resolve the tenant once per request, from the auth token, never from user input.
- Index every tenant id column; most queries filter on it.
- Test for cross-tenant leaks in CI, not just by hand.
- Rate limit and size quotas per tenant.
- Start pooled, and design so a large tenant can move to a silo later.
Want help acting on this?
Book a CallBring your answers to a free 30-minute call.