Multi-tenancy is the architectural heart of SaaS: one application serving many customers ("tenants") who must never see each other's data. Founders do not need to design it — but the decisions are expensive to reverse, so understanding the tradeoffs before your dev team picks one is cheap insurance. Here is the plain-language version.
The three isolation models
Shared everything (row-level). One database; every row tagged with tenant_id; the application (or better, the database itself) filters ruthlessly. Cheapest to run, easiest to ship features across all customers, scales to enormous tenant counts. The risk is a filtering bug leaking data across tenants — which is why 2026 practice enforces isolation in the database via row-level security, not just in application code. This is the right default for SMB-serving SaaS.
Schema/database-per-tenant. Each tenant gets a separate schema or database. Stronger isolation, per-tenant backups/restores, and "your data is physically separate" as a sales answer — at the cost of migration complexity (a schema change runs N times) and infrastructure overhead per tenant. Right when tenants are fewer and bigger, or compliance demands it.
Hybrid. Shared rows for the many, dedicated databases for the few enterprise accounts that pay for it. The pragmatic pattern for products spanning SMB and enterprise — and the reason to keep tenancy logic clean enough to support both (the modular discipline again).
The decisions that are expensive later
- Tenant identity from day one. Every table, every query, every cache key, every file path carries tenant context. Retrofitting tenancy into a single-customer codebase is a rebuild wearing a refactor's name.
- Isolation enforcement location. App-code filtering is one forgotten WHERE clause from a breach; database-enforced RLS makes the leak structurally hard. Insist on the latter — it is a one-line requirement in your scope document.
- Per-tenant configuration model. Feature flags, limits, branding, and billing plans per tenant — designed early, this is a settings table; bolted late, it is if-statements metastasizing everywhere.
- Noisy-neighbor controls. One tenant's bulk import should not slow everyone: rate limits and queue fairness by tenant.
What it means for your budget
Multi-tenancy is why SaaS builds cost more than single-customer tools — the Growth tier's price premium is largely this engineering. It is also why the premium pays: serving customer #200 costs nearly nothing extra when the architecture is right.
Scoping a SaaS? Ask any vendor which model they propose and where isolation is enforced — then ask us the same and compare answers.
Frequently asked questions
What is multi-tenant architecture?
One application serving many customers (tenants) whose data must stay strictly separated. It's the architectural core of SaaS — and why serving customer #200 costs nearly nothing extra when designed right.
Which tenancy model should a SaaS use?
Shared-database with database-enforced row-level security is the right default for SMB-serving SaaS — cheapest, most scalable. Schema-per-tenant suits fewer, bigger, compliance-heavy tenants. Hybrid (shared for many, dedicated for enterprise payers) spans both.
Where should tenant isolation be enforced?
In the database via row-level security, not just application code. App-layer filtering is one forgotten WHERE clause from a cross-tenant breach; database enforcement makes leaks structurally hard. Make it a written requirement.
Can multi-tenancy be added to an existing app later?
Painfully — tenant context must touch every table, query, cache key, and file path, so retrofitting is closer to a rebuild than a refactor. If SaaS is the plan, tenancy belongs in the first architecture conversation.