Home / Knowledge hub / Tenant isolation
Knowledge hub
Tenant isolation
What keeps one customer's data unreachable from another's session.
What it means
Tenant isolation is the arrangement in shared software that keeps one customer's data unreachable from another customer's session. Everybody uses the same application, and nobody sees across the boundary.
You can build it two ways. Structure enforces it, through how you store and query data, or discipline does, where every query is meant to carry a filter.
Why it matters
This is the failure customers fear most in shared software, and the one they will not forgive. Seeing another company's records is not a bug report. It is a phone call to their legal team.
It is also the question worth asking a vendor directly. Not whether tenants are isolated, but what enforces it, because an answer resting on every developer remembering something offers a different level of assurance. It shapes contracts as well, since some buyers ask for separate storage outright. It decides how much of an incident you can contain, too. When the boundary lives in one shared table, a single bad query reaches every customer at once.
How it shows up
The bug appears in the least glamorous places. An export job, a report, a search somebody added quickly, an admin screen, a cache key that forgot which customer it belonged to. The main screens are usually fine, because everybody tests those.
Database features such as PostgreSQL row level security move the check below the application, which helps when a query loses its filter. Unguessable identifiers only slow an attacker down. Test it with two real accounts in two tenants, each trying to reach the other's identifiers. Background jobs deserve a look as well, because a queue worker running without a tenant context is the classic place the filter disappears. That is what a role by resource matrix checks.
Questions people ask
Tenant isolation, answered
Is a shared database with a tenant id column safe enough?
It can be, and it puts the whole boundary inside your application code. One query that loses its filter leaks across customers.
That query is usually an export or a report rather than a main screen, which is why these bugs survive so long.
Is row level security enough on its own?
It is a strong layer, and it needs setting up carefully. Connect as a non-owner role, force the policy so owners obey it too, and set the tenant per request rather than per connection.
Set it per connection and a pooler will carry one tenant's context into the next request.
Should every customer get their own database?
Some buyers ask for it, and some regulated markets expect it. It costs more to run and more to operate.
Most teams start shared and move the customers who genuinely require separation.
How do we actually test tenant isolation?
With two real accounts in two different tenants. Take an identifier from one and try to reach it from the other, across every endpoint rather than the obvious screens.
That is the exercise a role by resource matrix automates.
Do unguessable ids fix this?
No. They make guessing slower, and they leak through exports, logs, URLs and support tickets anyway.
The check still has to happen on the server, on every request.
Related
Terms that sit next to this one
BOLA
An API returns a record just because you asked for it by number.
Broken access control
An application failing to enforce its own rules about who may do what.
Authorization
Deciding what a proven user is then allowed to do.
IDOR
Changing an id in a request and getting back someone else's record.
Access control
The rules deciding which person can see or do which thing in your app.
Can one customer reach another's data?
Cyberlop signs in as two accounts in two tenants, tries to reach across the boundary, and shows you the request that worked. Ask about testing your isolation properly.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.