Skip to content
Permissions & Organizations

02.04 · Lecture

Teams, Organizations & Multi-Tenancy

Choose between silo, pool and bridge tenant isolation for a SaaS product, and name what leaks first when you get it wrong.

SaaS tenant isolation is a boundary decision across infrastructure, data, operations and admin paths. Silo favours strong separation at higher cost, pool favours efficiency with stricter controls, and bridge mixes shared and dedicated layers. Bad isolation usually leaks first through caches, jobs, logs, metrics, support tooling or performance before obvious database rows.

What this lesson answers

  • silo vs pool vs bridge tenant isolation
  • what leaks first in multi tenant SaaS
  • how to choose SaaS tenant isolation model

Notes

Multi-tenancy means one product instance serves many customer groups, while still making each tenant feel private, safe, and predictable. The big choice is where to draw the boundary. In a silo model, each tenant gets mostly separate infrastructure or databases. In a pool model, tenants share infrastructure and data stores, with tenant identifiers and authorization checks separating them. In a bridge model, some layers are shared and some are isolated, such as shared application servers with separate databases for larger tenants.

A useful mental model is apartment housing.

Common questions

What is the difference between silo, pool and bridge tenancy?
Silo gives each tenant mostly separate resources, which is easier to reason about but more expensive to run. Pool puts tenants on shared resources and relies on tenant keys, authorisation and controls. Bridge uses a mixture, such as shared application services with dedicated storage for larger, regulated or higher-risk tenants.
Is multi-tenancy mainly a database schema decision?
No. The database is only one enforcement point. Tenant boundaries also have to hold in caches, queues, search indexes, background workers, logs, metrics, billing, support tools, feature flags, exports and backups. A clean schema does not protect you if operational paths or admin workflows ignore tenant scope.
What fails first when tenant isolation is wrong?
The first failure is often indirect leakage rather than another customer’s records. Metadata can appear in logs, timings can reveal activity, shared queues can cause noisy-neighbour effects, metrics can expose names, and support tools can cross scopes. Performance, observability and administration paths are common early weak spots.