Multi-tenancy and tenant isolation
When many companies use the same software, their data lives on shared machines. The quiet guarantee underneath is that no one can see into anyone else's rooms. That guarantee is tenant isolation.
Multi-tenancy is one running system serving many customers at once, the way one building houses many families. It is what makes modern software affordable to run and quick to update for everyone at the same time. This is an educational walk through the field, in plain language: what it is, why it is hard, how the boundary is built and enforced, what it unlocks, and where it is heading. The sources behind each idea are linked, so you can read them yourself.
One system, many customers, under the same roof.
The field name is multi-tenancy. A single running application, and the infrastructure under it, serves many independent customers, called tenants.
Each tenant gets a logically private experience. The provider gets one fleet to operate and update. This is the shared-resource model behind most cloud software, and it is what the NIST definition of cloud computing calls resource pooling: provider resources pooled to serve many consumers, dynamically assigned.
Multi-tenancy without isolation is just a data leak waiting to happen. So the model comes with a paired guarantee: tenant isolation, the property that one tenant cannot reach, observe, or degrade another. It has two distinct jobs, and the academic framing in Krebs et al. (2012) keeps them separate: data and security isolation, so one tenant's records are unreachable to every other, and performance isolation, so one busy tenant does not slow everyone else down.
One distinction worth keeping straight: a tenant is not the same as a user. A tenant is usually an organization, a customer company. Within a tenant there are many users with their own permissions. Isolation operates between tenants. Access control operates between users inside a tenant. Both matter, and a serious design treats them separately.
Efficiency and isolation pull against each other.
The more tenants share, the cheaper and easier to operate, but the thinner the wall between them. Every architecture is a chosen point on that trade-off, and the boundary is enforced in software.
Sharing is cheap, dedication is strong.
Share more and the system is cheaper to run and simpler to update for everyone at once, but the wall between tenants gets thinner. Dedicate more per tenant and the wall is stronger, but cost and operational overhead climb. This tension is the spine of the field.
One missing filter is everyone's problem.
In a shared model, isolation often comes down to a condition like "where tenant equals this one," applied everywhere, every time. One forgotten code path and one tenant can see another's data. The blast radius is the whole customer base, not one account.
A busy tenant can starve the rest.
Shared processor time, memory, database connections, and disk mean one heavy tenant can crowd everyone else out. Performance isolation, through quotas, rate limits, and reservations, is a first-class concern, not an afterthought.
Answer only from what a person may see.
Even inside one tenant, the system must answer only from data the asking person is allowed to see. NIST's access control guidance for cloud systems (SP 800-210) frames this as scoping every access path to the authenticated identity.
Where does my data live, and who can reach it.
Enterprise buyers ask where their data sits, who can touch it, and what happens if a neighbor is breached. The isolation model is the technical answer to those review questions, which is why it gets written down.
Onboarding, migration, and growth.
New tenants arrive. Some outgrow the shared pool and need promoting to dedicated resources. Schema changes have to apply to everyone at once. The shared model makes updates easy and migrations delicate.
The boundary is built from named, layered controls.
Pick a point on the spectrum, push enforcement into one place where you can, carry the tenant tag on every request, and never trust a single mechanism alone.
1The mental model
The isolation spectrum: silo, pool, bridge.
There is no single way to build the wall. It runs along a continuum. At the data layer, Chong, Carraro, and Wolter (2006) named three points: a separate database per tenant, a shared database with a separate schema per tenant, and a shared schema where one set of tables carries a tenant identifier on every row. Cost drops and density rises as you move toward fully shared. Isolation strength moves the other way.
The AWS silo, pool, and bridge framing generalizes that beyond the database to compute, storage, and networking: silo is dedicated resources per tenant, pool is shared resources with isolation enforced in software, and bridge is a hybrid that applies silo or pool per component, wherever each makes sense. Most real systems are a bridge.
| Pattern | Deployment shape |
|---|---|
| Silo | Dedicated resources per tenant. |
| Pool | Shared infrastructure with enforced tenant scope. |
| Bridge | A mixture of shared and dedicated components. |
2Enforce it in one place
The shared table, enforced by the database.
In a pooled database, a common way to enforce the tenant boundary is to push it into the database itself rather than trusting every query to remember it. PostgreSQL row security policies do exactly that: enable row-level security on a table, then write a policy that filters rows automatically based on a session value holding the current tenant.
The point is to centralize isolation in one enforcement point instead of scattering it across a thousand application code paths. One rule the database applies on every query, rather than a filter each developer has to remember to add. That is a smaller surface to get right, and a smaller surface to audit.
| Tenant | Record | Request from A |
|---|---|---|
| A | Acme renewal | Allowed by tenant scope |
| B | Other organization | Excluded |
| A | Northwind expansion | Allowed by tenant scope |
Only rows whose tenant_id
matches the verified request context.3Build it, do not switch it on
Isolation as a property you construct.
At the platform layer, the Kubernetes documentation on multi-tenancy treats it as a property you build, not a feature you flip. You layer the controls: namespace scoping to carve up the space, role-based access control for who can do what, network policies for who can talk to whom, and resource quotas as the noisy-neighbor guard.
It also draws a line worth borrowing: soft multi-tenancy, where the tenants are trusted teams inside one organization, versus hard multi-tenancy, where tenants are untrusted and external. Hard tenancy needs stronger separation, up to a dedicated control plane per tenant. The sensitivity of the data decides how far you go.
- Identity
Establish the authenticated tenant context.
- Authorization
Check the person’s allowed actions and resources.
- Data access
Apply tenant scope to queries, storage, and caches.
- Resource controls
Limit noisy-neighbor effects with quotas and scheduling.
4The tag on every request
Identity carries the tenant context.
Isolation is only as good as the tenant tag attached to each request. A token or session identifies the tenant, and every layer the request passes through, the application, the cache, the queue, the database, has to honor it. A request that loses its tenant context somewhere in the middle is a request that can cross the wall.
So real systems combine all of the above into defense in depth: tenant context in identity, row-level security in the database, quotas for performance, and dedicated resources for the most sensitive tenants. The discipline is to assume any one layer can fail and to make sure another still holds.
User Dana · tenant A · sales role
- Tenant boundary
Consider only tenant A’s data.
- User authorization
Select only records and actions permitted to Dana.
- Response
Return information from that allowed subset.
A clear isolation model is what lets a buyer say yes.
At the field level: affordable, fast-moving software, a credible answer to a security review, tenant-aware features done right, and a path to scale tenants independently.
For a sales setting the relevance is direct, and it stays at the level of the outcome. A co-pilot working across many client companies is, by definition, a multi-tenant system. Its evaluator will ask the standard isolation questions: is one client's pipeline walled off from another's, can a neighbor's problem reach me, and does the assistant answer only from records the asking person is allowed to see. Those are textbook tenant-isolation problems, expressed in the language of sales. They are offered here as examples of the field, not as claims about any one product.
Affordable, fast-moving software.
Sharing infrastructure is what lets a provider serve many customers economically and ship one update to everyone at once. Multi-tenancy is the business model under most cloud software, expressed as architecture.
An answer to the security review.
A clear model of which resources are dedicated, which are shared, and how the boundary is enforced is what lets a buyer's security team sign off. It turns "trust us" into "here is the boundary and here is how it holds."
Tenant-aware features, done right.
Per-tenant configuration and data, and answers that respect both the tenant wall and each user's permissions. As an example: one client's deals never bleed into another's, and a rep sees only what their role allows.
Room to scale tenants apart.
The bridge model lets a provider keep most tenants efficient in a shared pool while promoting a sensitive or heavy tenant to dedicated resources, without rebuilding the product.
For AI REV Voice's data protection and access controls, see Security & privacy. This explainer covers the underlying research.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
Silo-like assurance, pool-like economics.
Database-enforced policies, cell-based and shard-per-tenant patterns, and finer-grained quotas aim to get the assurance of dedicated resources closer to the cost of shared ones.
The boundary reaches retrieval and context.
As assistants and retrieval systems sit on top of tenant data, the tenant wall now has to be honored inside retrieval and model context, not only in the database. Tenant-scoped retrieval and per-tenant adaptation are an active frontier.
Hardware isolation as a complement.
Hardware-isolated execution is being paired with logical multi-tenancy to harden the shared model further. The companion explainer on secure enclaves covers it.
From design choice to published property.
Buyers increasingly expect the isolation model documented and attested. Expect tenant isolation to keep moving from an internal design decision toward a reviewable, written-down property.
There is no free lunch.
Every design picks a point on the isolation-versus-efficiency curve, and the right point depends on how sensitive the data is. Presenting it as a spectrum with trade-offs is the accurate framing, not an absolute guarantee.
The sources behind this page.
Academic papers where they exist, otherwise the standard or official documentation.
- Chong, Carraro, Wolter (2006). Multi-Tenant Data Architecture. Microsoft.
- Krebs, Momm, Kounev (2012). Architectural Concerns in Multi-Tenant SaaS Applications. CLOSER 2012.
- Amazon Web Services. SaaS Tenant Isolation Strategies: Silo, Pool, and Bridge Models. AWS Whitepaper.
- Mell, Grance (2011). The NIST Definition of Cloud Computing. NIST SP 800-145. Companion: General Access Control Guidance for Cloud Systems, NIST SP 800-210.
- The PostgreSQL Global Development Group. Row Security Policies. PostgreSQL Documentation.
- Kubernetes Documentation. Multi-tenancy.
Keep reading.
Sibling explainers in the Research section.
Talk. Done.
The field is deep, but the promise is plain: you talk, and clean, complete notes are waiting. See it on a real call.
No app required. Just your phone number.