Problem
SaaS must serve many tenants on shared infrastructure. No tenant should see another's data, affect performance, or bypass limits.
architecture-descriptionestablished · high operational burden
Tenant Isolation (Multi-Tenancy)
Also known as: multi-tenancy, tenant-isolation, saas-architecture
Intent
Share infrastructure across customers while isolating their data, compute, and blast radius.
Forces
- •Cost efficiency: share infra, not dedicated per tenant
- •Data isolation: regulatory, contractual, trust
- •Performance isolation: noisy neighbor problem
- •Operational: deploy once, configure per tenant
Solution
✓ When to Use
- •SaaS with >10 tenants
- •Regulatory data isolation (GDPR, HIPAA, FedRAMP)
- •Noisy neighbor risk (variable tenant load)
✗ When Not to Use
- •Single-tenant (dedicated deployment)
- •Very few tenants where dedicated is cheaper
- •Homogeneous workloads with no isolation needs
Pros
- +Cost efficiency at scale
- +Single deployment, configuration-driven
- +Tenant onboarding: config, not infra
Cons
- −Complexity: RLS, connection pooling, migration
- −Noisy neighbor: hard to eliminate completely
- −Cross-tenant queries: reporting, analytics harder
- −Security surface: one bug leaks all tenants
Cost Profile
Infrastructure
Low (shared) to High (dedicated)
Operational
High — tenant onboarding, migration, isolation testing
Cognitive
High — isolation model choice, failure domains
Failure Modes
RLS policy bug → cross-tenant data leak
Noisy neighbor: one tenant's load degrades others
Schema migration: partial failure → tenant inconsistency
Connection pool exhaustion: one tenant monopolizes
Backup/restore: single tenant restore in shared DB is hard
Real-World Examples
Alternatives
- single-tenant
- cell-based-architecture
- namespace-isolation
Related Patterns
- cell-based-architecture
- partitioning
- rate-limiting
- bulkhead
- rls
Competency Domains
security compliancedata statedistribution communicationeconomics evolutionreliability ops