Tenant Isolation Models Vocabulary
5 exercises — master the vocabulary of multi-tenant data isolation: pool, silo, and bridge models; row-level security; hybrid isolation; and data residency design.
0 / 5 completed
Tenant isolation vocabulary quick reference
- Pool model — shared database, shared schema; tenant_id column separates tenant data
- Bridge model — shared database, separate schema per tenant
- Silo model — dedicated database per tenant; maximum isolation
- Row-level security (RLS) — database-layer policy that enforces tenant filtering even if application code omits it
- Hybrid isolation — SMB tenants in pool, enterprise tenants in silo; same application codebase
- Blast radius — the scope of impact when a failure occurs; silo minimises blast radius
- Tenant data leak — cross-tenant data exposure caused by missing or incorrect tenant filtering
- Data residency — legal requirement that tenant data remains within a specified geographic region
1 / 5
A SaaS startup is building their first multi-tenant platform. The architect presents three options for tenant data isolation. She calls them pool model, silo model, and bridge model. Which description correctly defines each?
The pool, silo, and bridge models are the three foundational tenant isolation architectures.
Trade-offs:
Pool model pros/cons:
✓ Lowest operational overhead — one database to manage
✓ Best resource utilisation — tenants share idle capacity
✗ Highest cross-tenant leak risk — one query bug can expose all tenant data
✗ Noisy neighbour risk — one large tenant can degrade all others
Silo model pros/cons:
✓ Strongest isolation guarantee — complete data separation
✓ Ideal for enterprise/regulated customers who require isolation
✗ Operational complexity scales linearly with tenant count (1,000 tenants = 1,000 databases)
✗ Provisioning is slow and expensive
Bridge model pros/cons:
✓ Reasonable isolation (no cross-schema queries by accident)
✓ Easier to implement per-tenant features (e.g. per-tenant indexes)
✗ Still one database — resource contention possible
✗ Schema proliferation (10k tenants = 10k schemas) strains some DBs
Key vocabulary:
• Tenant context — the mechanism that ensures every query is scoped to the correct tenant
• Row-level security (RLS) — a database feature (e.g. PostgreSQL RLS) that enforces pool model isolation at the DB level
| Model | Database | Schema | Rows |
|---|---|---|---|
| Pool | Shared | Shared | Mixed — tenant_id column separates tenants |
| Bridge | Shared | Per-tenant schema | Isolated at schema level |
| Silo | Per-tenant DB | Per-tenant | Fully isolated |
Trade-offs:
Pool model pros/cons:
✓ Lowest operational overhead — one database to manage
✓ Best resource utilisation — tenants share idle capacity
✗ Highest cross-tenant leak risk — one query bug can expose all tenant data
✗ Noisy neighbour risk — one large tenant can degrade all others
Silo model pros/cons:
✓ Strongest isolation guarantee — complete data separation
✓ Ideal for enterprise/regulated customers who require isolation
✗ Operational complexity scales linearly with tenant count (1,000 tenants = 1,000 databases)
✗ Provisioning is slow and expensive
Bridge model pros/cons:
✓ Reasonable isolation (no cross-schema queries by accident)
✓ Easier to implement per-tenant features (e.g. per-tenant indexes)
✗ Still one database — resource contention possible
✗ Schema proliferation (10k tenants = 10k schemas) strains some DBs
Key vocabulary:
• Tenant context — the mechanism that ensures every query is scoped to the correct tenant
• Row-level security (RLS) — a database feature (e.g. PostgreSQL RLS) that enforces pool model isolation at the DB level