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
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