Multi-Tenancy 101 for Non-Technical Founders
Multi-tenancy is the least glamorous decision in SaaS and one of the most consequential. It answers a simple question: when you have 200 customers, are you running one piece of software they all share, or 200 separate copies? The answer shapes your costs, your security posture, and eventually your enterprise sales cycle — and it's nearly impossible to change cheaply once you're live.
The apartment building analogy
Single-tenant is a neighborhood of houses: every customer gets their own copy, their own database, their own everything. Isolation is perfect; economics are terrible — every upgrade is 200 upgrades. Multi-tenant is an apartment building: one structure, one roof to fix, with strong walls between units. Your costs grow gently while customers multiply. Virtually every successful SaaS you know is an apartment building.
Where founders get burned
The failure mode isn't choosing wrong — it's not choosing at all. A rushed MVP where every query just filters by customer ID, with no enforced isolation layer, works fine until the day a bug shows one customer another customer's invoices. That's not a bug report; that's a churn event and a security disclosure. Tenant isolation has to be enforced by architecture — at the database layer — not by every developer remembering to add a WHERE clause forever.
Questions to ask your dev team
- How is tenant isolation enforced — by convention or by the database itself?
- Can we give a big customer dedicated resources later without a rewrite?
- What does per-tenant backup and restore look like when a customer deletes something important?
- If an enterprise prospect demands data residency or a security review, what will we show them?