Multi-tenant SaaS: pool, bridge or silo?
The tenancy model shapes cost, isolation and operations for years. A practical guide to choosing it and to proving isolation works.
Key takeaways
- Pooled tenancy is cheapest and demands database-level isolation; siloed is simpler to isolate and costlier to run.
- Choose from data sensitivity, customer size and budget, not from habit.
- Write tests that deliberately try to read another tenant's data and run them on every build.
If you build software that many customers use, you will choose a tenancy model whether you intend to or not. Making the choice on purpose is cheaper than discovering it during a security review.
The three models
Pool
All tenants share the same tables, separated by a tenant identifier on every row. It is the cheapest to run and the easiest to onboard, because a new tenant is a new row rather than new infrastructure. The risk is that one missing filter leaks data between customers, and that a heavy tenant can slow the others.
Silo
Each tenant gets its own database, or its own full stack. Isolation is simple to explain and to audit, and tenant-specific backup, residency and customisation are easy. The cost is operational: many databases to migrate, monitor and pay for.
Bridge
A mix. Small tenants share a pool; large or regulated tenants are promoted to dedicated resources. It is a common destination for growing products.
How to choose
- Data sensitivity and regulation. Health, finance and public-sector customers often require stronger isolation or specific regions.
- Customer size and count. Thousands of small customers favour pooling; a few large ones may justify silos.
- Customisation. Heavy per-tenant schema changes are painful in a pool.
- Team and budget. A small team operating hundreds of databases will struggle.
Enforce isolation in layers
- Carry tenant identity from login to the query. The tenant is part of the authenticated context, not a parameter the client supplies.
- Enforce in the database. Row-level security policies mean a forgotten filter in application code cannot leak data.
- Constrain noisy neighbours. Per-tenant rate limits, quotas and queue isolation protect everyone from one heavy user.
- Test the boundary. Write automated tests that authenticate as one tenant and try to read, write and enumerate another's data. Run them in CI.
Plan the promotion path
Even in a pooled design, make it possible to move one tenant to dedicated storage later. Avoid cross-tenant joins, keep identifiers globally unique and keep tenant data exportable. That turns a future enterprise requirement into a project rather than a rewrite.
Offboarding
Decide at the start how a tenant's data is exported and deleted. It is much easier to design in than to retrofit when your first customer asks to leave.
See our multi-tenant architecture page for how we approach it, and SSO and identity for the enterprise features that usually follow.