Most SaaS founders don't pick a multi-tenancy model. They inherit one from whichever framework or tutorial they started with. Then around customer 50, the model breaks — and rewriting it costs 6-12 months.
This post is the framework we use to make the call, before the first line of code.
The three models
Row-level isolation
Every row in every table has a tenant_id column. Queries always filter by it. Mongoose middleware or row-level security policies enforce it.
- Best for: consumer SaaS, lots of small tenants, cost-sensitive
- Cost: lowest infra cost, simplest ops
- Risk: one bug in the filter exposes everyone's data
Schema-per-tenant
Each tenant gets its own Postgres schema (or Mongo database). Same Postgres server, separate logical container.
- Best for: B2B SaaS with mid-market customers who care about data isolation
- Cost: moderate ops, harder migrations
- Risk: schema sprawl at 1,000+ tenants; cross-tenant queries are painful
Database-per-tenant
Each tenant gets a dedicated database (often dedicated server or cluster).
- Best for: enterprise SaaS where compliance demands physical isolation
- Cost: expensive ops, expensive infra
- Risk: you become a database operator
The framework
Three questions, in order:
1. What does the customer contract require?
If your enterprise contract template promises "your data is stored in a dedicated database", you've already decided. Don't argue with the contract.
2. What's the noisy-neighbour risk?
If one tenant can plausibly spike to 1000x another tenant's load, row-level isolation will burn you. Schema or database isolation gives you per-tenant resource limits.
3. What's the auditor expectation?
SOC 2 Type II, HIPAA, PCI — auditors often expect to see physical or logical isolation per customer. Trying to argue row-level is "good enough" to an auditor wastes weeks.
What we usually pick
For most B2B SaaS engagements at NextGen, we land on schema-per-tenant by default. It survives the first enterprise deal without re-architecture, costs less to operate than DB-per-tenant, and gives auditors a clean answer.
Row-level only for clear consumer SaaS. Database-per-tenant only when compliance explicitly demands it.
The decision frame in one table
| Question | Row-level | Schema-per-tenant | DB-per-tenant |
|---|---|---|---|
| Cheapest to operate | ✅ | — | ❌ |
| Easiest cross-tenant queries | ✅ | — | ❌ |
| Best for B2B enterprise | ❌ | ✅ | ✅ |
| Lowest data-leak risk | ❌ | ✅ | ✅ |
| Auditor-friendly | ❌ | ✅ | ✅ |
| Scales to 10,000+ tenants | ✅ | ⚠️ | ❌ |
What to do today
Before you commit:
- Write down your likely customer profile in 18 months, not today
- Check your planned compliance scope
- Talk to the first 3 enterprise customers you plan to sell to — they will tell you exactly what they need
If you want a written recommendation for your specific case, book a call — we'll come back in 24 hours.