Multi-tenancy Study Portal

How it works

The spectrum in one picture

Left is cheapest and weakest, right is strongest and most expensive. Two further models, tiered and tenant sharding, are not points on the line but ways of mixing it.

1. Pool (shared schema + tenant column)

In plain words: everyone's rows live in the same tables, and each row carries a tenant_id saying whose it is.

• Where the wall is: in application code — every query must add WHERE tenant_id = ?.
• Pros: cheapest per tenant; one schema to migrate; onboarding a tenant is an INSERT; cross-tenant analytics and cross-tenant users are easy.
• Cons: one missed filter leaks data (the wall is only as strong as the least careful query); noisy neighbours share one database; per-tenant backup/restore is hard; a large tenant skews indexes and statistics for everyone.
• How the filter is made unforgettable: an ORM global query filter (EF Core HasQueryFilter, Hibernate filters, a Django default manager) adds the predicate to every query built through the ORM. Raw SQL, bulk jobs and reporting tools bypass it, which is why RLS (model 2) is the usual second step.
• Who uses it: the default for most B2B SaaS; Salesforce's architecture docs describe one shared database and one schema for all orgs, every row scoped by an org id.
• Sources: AWS SaaS Lens — silo, pool and bridge models · Azure — multitenant SaaS database tenancy patterns · EF Core — global query filters, multi-tenancy example · Azure — storage and data approaches for multitenant solutions · Citus — multi-tenant apps · Salesforce — platform multitenant architecture

2. Pool + database row-level security (RLS)

In plain words: still shared tables, but the database itself hides rows that do not belong to the current tenant, even if the query forgets to filter.

• Where the wall is: in the database engine — a policy such as USING (tenant_id = current_setting('app.tenant_id')::uuid) is applied to every statement on the table.
• Pros: defence in depth — the application filter and the database policy must both fail for a leak; works for ad-hoc SQL and reporting tools too; keeps pool economics.
• Cons: the tenant context must be set on every connection (pooled connections must reset it, or a request inherits the previous tenant); superusers and table owners bypass RLS unless FORCE ROW LEVEL SECURITY is set; policies add planner work and can hide index use if written carelessly; still one database for noisy neighbours.
• Who uses it: Postgres-backed SaaS generally; Nile builds its tenant-aware Postgres around it; Supabase exposes it as the primary access-control mechanism.
• Sources: PostgreSQL docs — Row Security Policies · AWS — Multi-tenant data isolation with PostgreSQL RLS · SQL Server — Row-Level Security (multi-tenant example) · Nile — multi-tenant RLS

3. Bridge (schema per tenant)

In plain words: one database, but each tenant gets its own copy of the tables in its own schema (namespace).

• Where the wall is: in the schema — the connection's search_path (or a schema prefix) points at one tenant's tables.
• Pros: a forgotten WHERE cannot cross tenants; per-tenant backup, export and deletion are easy (dump or drop one schema); a tenant can be moved to its own database later.
• Cons: migrations run N times and can half-fail, leaving tenants on different schema versions; catalogue size grows with tenants × tables (thousands of schemas strain Postgres metadata and tooling); cross-tenant reporting needs a union over every schema; a user or integration that spans two tenants needs two search_path switches and an application-side merge; connection pooling per schema is awkward.
• Who uses it: common in Rails and Django SaaS (the apartment and django-tenants libraries); Influitive documented running its advocacy platform this way.
• Sources: AWS SaaS Lens — bridge model · django-tenants documentation · PostgreSQL — Schemas · Apartment gem README · Crunchy Data — designing Postgres for multi-tenancy · AWS Prescriptive Guidance — Postgres SaaS decision matrix

4. Silo (database per tenant + tenant catalogue)

In plain words: every tenant gets its own database, and a small shared "catalogue" maps each tenant to where its database lives.

• Where the wall is: at the database boundary — a request for tenant A physically connects to A's database.
• Pros: strong isolation, easy to explain to auditors; per-tenant backup, restore, encryption keys, region and sizing; no noisy neighbours at the data layer; a tenant can be deleted by dropping its database.
• Cons: cost per tenant (each database has a floor price); fleet operations — migrations, monitoring and upgrades across hundreds of databases; cross-tenant queries and users who belong to several tenants need a separate layer; the catalogue becomes a critical dependency; every database carries its own connections and memory, so on a small server the cost grows with the tenant count, not the data.
• Who uses it: enterprise and regulated SaaS; Azure SQL elastic pools and the "database per tenant" pattern are built for it. Atlassian's engineering blog describes Jira running one PostgreSQL database per tenant, millions of databases across a few thousand database instances.
• Sources: Azure — database-per-tenant pattern · AWS SaaS Lens — silo model · Azure — tenancy models, horizontally partitioned deployments · Atlassian — migrating Jira's database platform

5. Full-stack silo (Deployment Stamps)

In plain words: each tenant, or small group of tenants, gets its own complete copy of the application — compute, database, queues — called a stamp or cell.

• Where the wall is: at the infrastructure boundary; tenants share nothing but the control plane and the routing layer.
• Pros: maximum isolation, including performance and blast radius (a bad deploy or overload hits one stamp); data residency by placing stamps in regions; scales out by adding stamps rather than growing one giant system.
• Cons: highest cost; requires mature automation (infrastructure as code, fleet deploys, per-stamp monitoring); rollouts across stamps take time and can drift; cross-stamp features are hard, and an integration that serves several tenants needs a separate login per stamp.
• Who uses it: ServiceNow's multi-instance model gives each customer dedicated application nodes and a dedicated database; Atlassian Cloud and many hyperscale services run cell-based architectures; the Deployment Stamps pattern is documented by Microsoft, cells by AWS.
• Sources: Azure Architecture Center — Deployment Stamps pattern · AWS — Reducing the scope of impact with cell-based architecture · Azure — tenancy models, automated single-tenant deployments

6. Tiered pool + silo

In plain words: most tenants share a pool; the few who pay for (or legally need) isolation get their own silo, running the same code.

• Where the wall is: it depends on the tenant's tier, recorded in the catalogue.
• Pros: pool economics for the long tail and silo guarantees for the enterprise customers who fund them; isolation becomes a product tier you can price.
• Cons: two operating models to maintain and test; code must be tier-agnostic (no pool-only shortcuts); migrating a tenant between tiers is a real data-migration project.
• Who uses it: very common in B2B SaaS pricing — "dedicated instance" or "single-tenant" enterprise plans on top of a shared plan (ServiceNow-style dedicated instances are the far end of this). Atlassian keeps most Jira tenants on shared infrastructure and moves the very largest onto dedicated infrastructure.
• Sources: AWS SaaS Lens — tiering and mixed models · Azure — tenancy models, vertically partitioned deployments · AWS SaaS Architecture Fundamentals — full stack silo and pool · Azure SQL — hybrid sharded multitenant model

7. Tenant sharding (distributed database keyed by tenant)

In plain words: keep the pool model's shared tables, but spread tenants across many database nodes, keeping each tenant's rows together on one node.

• Where the wall is: still the tenant column (plus RLS if added); the sharding is about scale, not isolation.
• Pros: the pool model grows past one machine; queries scoped to one tenant stay on one node and stay fast; large tenants can be moved to their own node.
• Cons: cross-tenant queries fan out to every node; choosing tenant_id as the distribution key must be done early (every table needs it, including in primary keys); rebalancing is an operational event.
• When it is premature: it solves a data-size problem. Until one server (plus read replicas) cannot hold the pool, it only adds nodes to run.
• Who uses it: Citus (Postgres) was built around this for multi-tenant SaaS, and Freshworks runs Citus for billions of rows; Vitess shards MySQL similarly.
• Sources: Citus docs — multi-tenant applications · Vitess — sharding · Azure SQL — sharded multitenant databases

Comparing the models

Figures are orders of magnitude from vendor guidance, not benchmarks.

Choosing a model

Answer these in order; each one eliminates models.

1. How many tenants, and how big is the biggest? Thousands of small tenants rule out schema-per-tenant and full-stack silos on cost and operations.
2. What isolation do customers or regulators demand? A contract that says "our data in a separate database" or a residency law settles it regardless of cost.
3. Can one user belong to several tenants, or must you query across tenants? Silos make both expensive; pool makes them easy.
4. What is the blast radius you can accept? If one tenant's load or one bad deploy must not affect others, you are heading toward stamps.
5. Can you automate a fleet? Silo and stamps are only as good as your migration and deploy automation.

Refuse on the constraint first. If one user or integration must read two tenants in a single call, bridge, silo and stamps are out before cost is even compared. If you plan to consolidate services onto one database, the physically separated models fight that plan too.

Resolving the active tenant

Once a user can belong to more than one tenant, every request must say which tenant it acts for, and the data layer needs that answer before its first query.

A header or path is only a selector: the server accepts it only if the authenticated user holds a membership in that tenant. Removing a membership should cut access as fast as removing any other permission (see token versioning in the Authorization models module).

Tenant wall plus grants: two layers

Tenancy and permissions answer different questions, and keeping them separate is what makes a forgotten check survivable.

With the tenant wall in the data layer, a handler that forgets its permission check can still over-share inside one tenant, but it cannot leak another tenant's rows. Without it, every handler is one missing if away from a cross-tenant breach.