Tenancy
Multi-tenancy
One running system serving many separate customers, each of whose data must remain invisible to the others.
What Multi-tenancy means
Multi-tenancy is a single deployment serving many customers — tenants — from shared infrastructure, where each tenant's users, data and configuration are kept separate. The architectural question is never whether tenants are separated, but where that separation is enforced: in application code, in the database, or in separate infrastructure per tenant.
How it works
There are three broad approaches and they trade the same two things against each other. Separate infrastructure per tenant gives the strongest isolation and the highest operational cost — every upgrade, migration and incident is multiplied. A shared database with a tenant column on every row is the cheapest and puts the entire guarantee in application code. Between them sits enforcement at the data layer, where the database itself will not return another tenant's rows regardless of what the query asks for.
The distinction matters because of how multi-tenant systems actually fail. They do not usually fail at the login screen. They fail on one endpoint, written eighteen months after the pattern was established, where a developer filtered by user and forgot to filter by tenant — and that endpoint returns another customer's data to a perfectly authenticated user. Code review catches most of these. Most is not a number you want attached to this class of bug.
Multi-tenancy also shapes identity specifically. The same email address may belong to different people in different tenants. A user may legitimately exist in several tenants with different roles. Session policy, password rules and branding often differ per tenant because different customers have different obligations. A single-tenant identity model bent into this shape carries those assumptions with it.
The mistake people actually make
Treating the tenant identifier as an ordinary filter. Once it is one condition among several in a WHERE clause, the guarantee is only as good as the last person who wrote a query — and the failure is silent, because the request is authenticated and the response looks normal.
In Authreads
How this applies here
Isolation is enforced at the data layer: a request scoped to one tenant is structurally unable to read or write another tenant's users, sessions or policy, rather than being prevented from doing so by an application-level check.
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
- B2B login flows: invitations, domains, SSO and the first admin
- Identity for B2B SaaS: what the product needs at each stage
Related terms
Tenant isolation
The guarantee that one tenant's data cannot be read or written by a request scoped to another tenant.
Hosted login
A sign-in page served by the identity provider, which the application redirects to.
Session revocation
Ending an active session so that subsequent requests fail, rather than waiting for a token to expire.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.