Tenancy
Tenant isolation
The guarantee that one tenant's data cannot be read or written by a request scoped to another tenant.
What Tenant isolation means
Tenant isolation is the property that a request belonging to one customer cannot reach another customer's data. What varies between systems is where it is enforced — and a guarantee enforced only in application code is a guarantee that every future query has to re-earn.
How it works
Application-level isolation means every query includes the tenant scope because the developer remembered to add it. It works, it is the most common approach, and its failure mode is a single omission on a single endpoint that nothing tests for, because the test would have to be written by the same person who forgot.
Data-layer isolation means the store will not return another tenant's rows even if asked. In PostgreSQL this is typically row-level security tied to a session variable set from the authenticated context: the policy is evaluated by the database, so a query missing its tenant predicate returns nothing rather than everything. The scope is not a condition the developer supplies; it is a condition the database imposes.
The security review question is therefore not 'do you isolate tenants' — everyone says yes — but 'what happens if a developer forgets'. Those two answers describe very different systems, and the difference only becomes visible during an incident.
The mistake people actually make
Assuming an ORM's default scope is isolation. Scopes are opt-in, raw queries bypass them, background jobs frequently run outside the request context that carries the tenant, and reporting queries are written against the database directly by someone who has never seen the scope at all.
In Authreads
How this applies here
Enforced at the data layer, not only in application code — this is the specific design decision the platform is built on.
Every capability is listed on /roadmap as Available, In progress or Planned. Nothing is described as available here that is not listed as Available there.
Guides that go deeper
- Tenant isolation models: silo, bridge and pool compared
- Designing identity for a multi-tenant SaaS product
- Organization switching: letting one user belong to many tenants
- How to test tenant isolation before a customer finds the gap
- Identity for B2B SaaS: what the product needs at each stage
- Security questions to ask an identity provider (and what good answers look like)
Related terms
Multi-tenancy
One running system serving many separate customers, each of whose data must remain invisible to the others.
Session revocation
Ending an active session so that subsequent requests fail, rather than waiting for a token to expire.
Machine identity
Credentials issued to a service, workload or agent rather than to a person.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.