Single-tenant vs multi-tenant SaaS architecture
The fundamental difference
Multi-tenant. One application serves all customers; data segregated by workspace ID at the application and database layer. Most modern SaaS.
Single-tenant. Each customer gets their own deployment, database, infrastructure. More expensive but more isolated.
Cost comparison
For 1,000 customers:
- Multi-tenant. Shared infrastructure: roughly $5,000 to $20,000 per month total.
- Single-tenant. Per-customer infrastructure: roughly $50 to $500 per customer per month. Total $50,000 to $500,000.
The gap widens with customer count, because shared infrastructure is paid for once.
Isolation
Multi-tenant. Logical isolation: every query filters by tenant_id. Code paths enforce this at every layer. Tested rigorously.
Single-tenant. Physical isolation: separate databases, networks, possibly hardware. Provably isolated.
When multi-tenant fits
- Standard B2B SaaS. Most buyers.
- No regulatory requirement for physical isolation.
- Scale matters. Sharing infrastructure is the economic enabler.
When single-tenant fits
- Regulated industries with strict isolation requirements.
- Government contracts mandating dedicated infrastructure.
- Enterprise security postures that require provable isolation.
- Latency-sensitive workloads needing dedicated compute.
Few buyers truly need single-tenant; it is usually a regulatory or contractual requirement.
Hybrid models
Most modern SaaS offer both:
- Multi-tenant by default for cost efficiency.
- Single-tenant or dedicated-instance on Enterprise for customers who need it.
AskVault runs multi-tenant on every plan, including Enterprise, in a single US region. It does not offer dedicated infrastructure today.
Trade-offs summary
| Dimension | Multi-tenant | Single-tenant |
|---|---|---|
| Cost per customer | Low | High |
| Isolation guarantees | Logical | Physical |
| Update speed | Faster (one deploy serves all) | Slower (per-customer) |
| Customization | Limited | Unlimited |
| Compliance complexity | Per-customer evidence harder | Easier |
| Scalability | High | Lower per-deployment |
How AskVault implements multi-tenant
Every workspace's content is kept separate from every other customer's, and every request is checked against the workspace it belongs to:
- Every request is scoped to one workspace. A request that doesn't carry a valid workspace context is rejected.
- Searches only look inside your workspace. Content from other workspaces is never considered when your agent finds an answer.
- Identifiers are random. Workspaces, documents and conversations use random identifiers that can't be guessed or counted.
- API keys are bound to one workspace. A key can't read or write anywhere else.
We test cross-workspace leakage rigorously. Single bug here would be catastrophic; we treat as P0 priority.
Compliance considerations
For SOC 2 audits:
- Multi-tenant. Customer-data segregation evidence required. Tests and audits.
- Single-tenant. Inherent segregation; simpler evidence.
For HIPAA:
- Multi-tenant with BAA. Acceptable; many platforms do.
- Single-tenant. Often preferred for highest-PHI workloads.
For GDPR:
- Both work. Multi-tenant requires more documentation; single-tenant is self-evident.
Common pitfalls
Choosing single-tenant unnecessarily. You pay a large premium for a benefit you may not need.
Multi-tenant without audit evidence. Auditors expect proof of segregation. Test and document.
Mixing approaches mid-product. Hard to migrate. Pick early.
FAQ
Can a multi-tenant SaaS support HIPAA?
In general, yes, with a BAA and proper controls. AskVault does not currently offer a BAA and should not be used for PHI. See HIPAA at AskVault.
Will single-tenant scale better?
Only for the individual customer. Multi-tenant scales the platform more efficiently.
Should I demand single-tenant from a vendor?
Only if regulation requires. Otherwise multi-tenant is fine.