The single most consequential early decision in a SaaS product is how you isolate tenant data. Get it wrong and you're looking at a painful migration once you have real customers and real data to move. Get it right and it barely comes up again for years.
The three isolation models
| Model | Description | Best for |
|---|---|---|
| Shared database, shared schema | All tenants in the same tables, separated by a tenant_id column | Early-stage products, cost-sensitive scaling |
| Shared database, separate schemas | One database, one schema per tenant | Mid-size B2B products needing stronger isolation |
| Database per tenant | Fully separate database per customer | Enterprise/regulated customers requiring hard isolation |
Shared schema: the pragmatic default
For most SaaS products, especially pre-product-market-fit, shared schema with a tenant_id on every table is the right starting point. It's the cheapest to operate, the simplest to migrate, and scales further than most teams expect before it becomes a real bottleneck.
The catch: every single query needs the tenant filter, with no exceptions. A missing WHERE tenant_id = ? clause is a data leak, not a bug report. This is why row-level security at the database layer, not just application-level filtering, is worth setting up early — it's a safety net for the mistake every team eventually makes.
When to move to schema or database-per-tenant
The signals that it's time to move away from shared schema: enterprise customers requiring contractual data isolation guarantees, tenants with wildly different data volumes causing noisy-neighbor performance problems, or regulatory requirements (healthcare, finance) that mandate physical separation. Don't move preemptively — this adds real operational complexity (migrations now run per-tenant, connection pooling gets harder) that most products don't need on day one.
Billing and subscription logic
Treat billing state as a first-class part of the data model, not a bolt-on. Plan tier, usage limits, and billing status need to be checked consistently across the application, ideally through a single access point rather than scattered conditionals. This becomes especially important once you have usage-based pricing — metering needs to be accurate and auditable, not approximate.
Role-based access control
Multi-tenant products almost always need two layers of permissions: what a tenant's plan allows (feature access) and what a specific user within that tenant is allowed to do (role-based access). Keep these separate in your data model — conflating "can this tenant use this feature" with "can this user perform this action" leads to permission bugs that are hard to reason about later.
Common mistakes
- No tenant isolation testing. Write tests that specifically try to access another tenant's data and confirm they fail — this is worth testing explicitly, not just hoping the filters are correct everywhere.
- Choosing database-per-tenant too early. This multiplies operational overhead — migrations, backups, monitoring — before you have the customer base to justify it.
- Ignoring the noisy-neighbor problem. One tenant running an expensive query shouldn't degrade performance for everyone else on a shared database.
- Hardcoding limits instead of modeling them. Plan limits change. Store them as data, not constants in code.
Recommended approach
Start with shared schema and strict, tested tenant filtering — including database-level row security as a backstop. Model billing and access control as explicit, centralized systems rather than scattered checks. Move to stronger isolation models only when a specific customer requirement or scale problem actually demands it, not preemptively.
Conclusion
Multi-tenant architecture decisions are expensive to reverse, which is exactly why they deserve real thought before the first line of code — not because the "wrong" choice is unworkable, but because migrating tenant isolation models with live customer data is one of the more painful projects a SaaS team can take on.
Kiaanlab designs multi-tenant SaaS platforms with isolation, billing, and access control built as first-class systems from the start. Tell us about your product and we'll help you get the architecture right the first time.