Every SaaS company answers one architecture question before all others, usually without noticing: when ten thousand customers use one product, who shares what? That's multi-tenancy — and it's not one decision but a stack of them: how you deploy, how you isolate each layer, where each tenant's data lives, and even what industry you sell into. The best mental model is still housing — hostel, flat, house, gated community — but the full taxonomy has more floors than most posts admit. Here's all of it.
A real techdiagrams document — download the JSON and import it into the editor via File → Import.
Level 1 — Deployment posture: single, multi, or hybrid
Download this diagram to import it into the editor.
Before any database talk, there's the whole-stack question:
Single-tenant — every customer gets a dedicated copy of everything: app, database, infrastructure. Maximum isolation and customization, trivial per-customer cost attribution — and the operational profile of running hundreds of tiny products. This is where "enterprise on-prem-ish" deals and heavily regulated deployments live.
Multi-tenant — one deployment serves everyone; the rest of this post is about how much is shared inside it.
Hybrid (mixed) tenancy — the shape almost every successful SaaS converges on: free and standard tiers on shared infrastructure for unit economics, enterprise tiers on dedicated resources for compliance and blast radius. Not a compromise — a pricing strategy expressed as architecture.
Level 2 — The isolation vocabulary: silo, pool, bridge
Download this diagram to import it into the editor.
AWS's SaaS literature gave the industry its standard words, and they're worth using precisely:
Silo — a tenant gets dedicated resources. No noisy neighbors, clean cost tracking, limited blast radius, per-tenant compliance — at per-tenant cost.
Pool — tenants share resources, with isolation enforced logically (a tenant identifier on every row, request, and metric). Best economics, fastest iteration — and the noisy-neighbor and blast-radius risks come with it.
Bridge — the honest answer for real systems: silo and pool mixed per layer. Pooled web tier, siloed databases. Pooled everything except the compliance-sensitive microservice. The modern refinement goes further: in a microservices architecture, silo-vs-pool is decided per service — your auth service might be pooled for everyone while your document store is siloed for enterprise tenants. The diagram above is a bridge: shared app tier, split data tier.
Level 3 — The data-layer ladder (the housing analogy lives here)
Download this diagram to import it into the editor.
Shared tables + tenant_id (pooled — the hostel). One schema, everyone's rows interleaved. Cheapest per tenant; cross-tenant analytics is a GROUP BY. The costs: one forgotten WHERE tenant_id = ? is a cross-customer data leak — which is why row-level security belongs here as defense-in-depth — one corrupted table is everyone's incident, and single-tenant restore is surgery.
Schema-per-tenant (the flat). Same database, a namespace per tenant: tenant_042.orders. Real permission boundaries and plausible per-tenant restore; the tax is running every migration a thousand times, and schema drift is this model's signature disease.
Database-per-tenant (the silo — the house). Own database, backups, restore, upgrade window, encryption keys. Blast radius: one tenant. What enterprise buyers mean by "isolation," and what data-residency law sometimes requires ("EU tenants stay in the EU" is trivial when a tenant is a database you can place). Costs: per-tenant floor cost, connection-pool explosion, fleet-scale operations.
Hybrid-sharded (the housing association). The Azure-canonical middle path: small tenants share multi-tenant databases, big ones get their own, and — the key property — tenants migrate between them as they grow. It's the data-layer version of the lifecycle idea below.
Cell-based (the gated community). Shard the entire stack — app, data, cache — into self-contained cells, each home to a tenant group. A bad deploy takes down one cell, not the product (cell-based template).
Level 4 — Compute-layer tenancy
Download this diagram to import it into the editor.
The same ladder exists for compute, and it's decided independently: a shared stateless fleet (the default — the diagram's app tier), namespace-per-tenant on Kubernetes (quotas and network policies per tenant, one cluster), up to cluster-per-tenant for the truly regulated. Most teams pool compute long after they've siloed data — stateless tiers share safely; state is where isolation earns its cost.
The business lens: horizontal vs vertical SaaS
One more axis, because it drives all the others: horizontal SaaS (Slack, Notion — every industry) lives or dies on unit economics, so it pools aggressively. Vertical SaaS (healthcare records, banking, legal) sells into regulated industries where isolation is a procurement checkbox — so it skews silo and hybrid from day one, and often single-tenant at the top tier. If you're vertical, budget for the right side of every ladder above earlier than you'd like.
What no model escapes
Noisy neighbors — in any pooled layer, one tenant's batch import is another's latency spike; quotas and rate limits must be per-tenant, and a persistently heavy tenant is a hot shard wearing a company name. The router — the indirection between "tenant" and "where their stuff lives" (the diagram's front door) is what makes tier moves a migration instead of a re-architecture; build it when you have one database. The lifecycle — tenants climb the ladder as they grow; design the promotion path, not just the tiers. The boundary test — whatever the model: can tenant A ever read tenant B's data? Test it relentlessly; cross-tenant leaks are the SaaS incident companies don't recover from.
Decide with one question
"What happens to my other customers on my biggest tenant's worst day?" If the answer is "nothing," your ladder is right. If it's "everyone suffers," you've found the tenant that needs the next rung. The multi-tenant SaaS template composes the whole picture as an importable architecture — and this post's diagram is a bridge-model starting point for mapping your tenants onto it.