Tenant Isolation
Tenant isolation keeps one customer's data and workload from being observed, modified, or slowed by another, across storage, compute, caches, and background jobs.
Definition
Tenant isolation is the set of architectural and enforcement controls that prevent one tenant from accessing another tenant's data or consuming its capacity, spanning identity, queries, storage, caches, queues, and rate limits.
Context and scope
Use it in any multi-tenant SaaS system, and re-evaluate it whenever a new data store, cache, job, or integration path is added.
Common misconceptions
- A tenant_id column provides isolation; every query, cache key, and job must enforce it
- Isolation is only about security; noisy neighbors are an isolation failure too
- Siloed infrastructure removes the need for application-level checks
Anti-patterns
- Taking tenant identity from a request body or query parameter instead of the verified token
- Caching responses under a key that omits the tenant
- Running background jobs without a tenant scope, then scanning all rows
Related concepts
Authoritative source
https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html
Isolation has many layers
Tenant isolation is not a single database setting. It is a property of the whole path: the token that identifies the tenant, the query that filters rows, the cache key that stores a response, the queue message that triggers work, the object storage prefix, the encryption key, and the rate limiter that protects shared capacity.
How it works
The strongest model is silo: dedicated infrastructure per tenant, which limits blast radius but multiplies cost. Pool places many tenants in shared infrastructure with a tenant discriminator on every record and query. Bridge mixes both, often giving regulated customers dedicated shards while small customers share.
Whatever the model, derive tenant identity from a verified credential and propagate it as request context. Enforce it at the data layer with row-level security as a backstop, include it in every cache key and job payload, and scope storage paths and encryption keys per tenant.
When to use it
Every multi-tenant product needs it. The model choice depends on regulation, contract terms, and cost. Health, financial, and government customers often require silo or dedicated keys; long-tail customers rarely justify it. Add isolation tests that attempt cross-tenant reads with a valid token for another tenant.
Trade-offs
Silo gives the clearest boundary and the highest operational overhead. Pool is efficient but one missing filter becomes a breach. Shared caches and connection pools improve performance but blur boundaries. Per-tenant keys improve cryptography and complicate rotation. Noisy-neighbor controls add fairness logic and can reduce peak utilization.
Example and misconceptions
A report endpoint caches results under report:daily. Tenant A requests the report, then tenant B receives A’s cached data. Adding the tenant to the key fixes the leak; adding a cross-tenant test would have caught it.
The common misconception is that the database schema enforces isolation. It only does so if every access path uses it, including analytics jobs, admin tools, and support impersonation.
Related concepts: Multi-Tenancy, Row-Level Security, and Cache Keys.