Multi-tenant architecture
Tenant isolation models: silo, bridge and pool compared
Database-per-tenant, schema-per-tenant and shared tables with row-level security: what each isolates, what each costs, and how identity fits.
The short answer
There are three common ways to isolate tenants' data: a separate database or stack per tenant (silo), a separate schema per tenant in a shared database (bridge), or shared tables with a tenant column (pool). Silo gives the strongest isolation at the highest operational cost; pool is the cheapest and is only safe when the database itself enforces the tenant boundary, for example with row-level security, rather than every query remembering to.
Sources last reviewed .
The three models
- Silo: one database (or full stack) per tenant. Blast radius is one tenant; per-tenant backup, restore and data residency are simple. Every migration, upgrade and connection pool is multiplied by the tenant count.
- Bridge: one schema per tenant. Easier per-tenant restore than pool, fewer resources than silo; schema migrations still fan out, and catalogue size grows with tenants.
- Pool: shared tables keyed by tenant_id. Cheapest and simplest to operate. Isolation is a property of every query unless enforced underneath them.
Making pool safe
PostgreSQL row-level security lets you attach a policy to a table — for example, rows are visible only where tenant_id equals a setting established for the current transaction from the authenticated context. With RLS forced on the table and the application connecting as a role that does not bypass it, a query that forgets its tenant predicate returns nothing rather than everyone's rows.
Two details decide whether this works: the application role must not own the tables or hold BYPASSRLS, and the tenant setting must be scoped to the transaction so a pooled connection cannot carry one tenant's context into another's request.
Where identity sits
Isolation starts at authentication: the tenant context must come from the verified session or token, never from a request parameter the client controls. The identity layer is also multi-tenant data — users, sessions, policies — and needs the same isolation as the product it protects.
Choosing
Most B2B products start with pool plus database-enforced isolation and move specific large or regulated tenants to silo when a contract requires it. Choose a design where that move is possible without rewriting authorization.
In Authreads
How this applies to Authreads
Authreads enforces tenant isolation at the data layer, so a request scoped to one tenant cannot read or write another tenant's users, sessions or policy even if application code omits a tenant filter.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Keep reading
Multi-tenant architecture
Designing identity for a multi-tenant SaaS product
Multi-tenant architecture
How to test tenant isolation before a customer finds the gap
Multi-tenant architecture
Organization switching: letting one user belong to many tenants
Glossary: Tenant isolation · Multi-tenancy · Row-level security (RLS)
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.