Compare pooled and separated tenant architectures across data, jobs, storage and operations. Make tenant isolation explicit instead of relying on login alone.
Multi-tenancy lets one service support several customer organisations. The important design question is where resources are shared and how each tenant’s access and workload are constrained. Authentication establishes who is calling; it does not by itself establish which tenant resources that caller may use. Treat tenant isolation as a requirement across every execution path, including support tools and background processing.
Choose boundaries from requirements
| Model | Potential advantage | Operating question |
|---|---|---|
| Shared tables with tenant identifiers | Efficient shared infrastructure and common migrations | How is tenant filtering enforced and verified everywhere? |
| Separate schemas or databases | A clearer data boundary and possible tenant-specific operations | How will migrations, connections and backup operations scale? |
| Separate deployment resources | More independent capacity and configuration boundaries | Can the team provision, monitor and update the growing fleet? |
These models can be combined. A service might share its control plane while isolating a particular workload for a customer with different requirements. Document why the boundary exists and how onboarding selects it. Separate storage does not automatically guarantee isolation if application credentials, support tools or exports can cross the boundary without appropriate checks.
Carry trusted tenant context through the system
Resolve tenant membership and permissions at the server boundary. Do not treat a tenant identifier supplied in a request as proof of access. Include the context in queued work, cache keys, storage paths and audit records, then validate it at the point where resources are accessed. Review privileged cross-tenant operations separately and limit them to explicit administrative purposes.
Test more than the happy-path API
- Create representative accounts in two test tenants with distinct records.
- Verify reads, updates, exports and attachments across the intended role boundaries.
- Exercise delayed jobs and cached responses after switching tenant context.
- Check support actions and record the actor, tenant and purpose.
- Test recovery and deletion procedures against the chosen tenant boundary.
Isolation also has an operational dimension. One tenant’s large import or expensive report can consume shared capacity without exposing any data. Define quotas, scheduling or workload separation where required, and measure whether the service meets its commitments under representative load. Keep a tenant inventory and versioned provisioning process so onboarding does not drift into undocumented exceptions. Review the architecture when customer requirements or workload patterns materially change.
- SaaS development
- SaaS MVP Features: What to Include Before Your First Customers
- Technical Due Diligence for SaaS Acquisitions
Frequently asked questions
Is a tenant identifier in every table enough?
No. Queries, jobs, caches, files and administrative operations must use and enforce trusted tenant context consistently.
Does each tenant need its own database?
Not always. Choose the boundary from isolation, recovery, scale and operating requirements, and account for the cost of managing it.
Can database separation replace authorization?
No. The application and operational access paths still need authorization and controlled credentials.
How do we test isolation?
Use authorised test accounts in distinct tenants and verify relevant reads, writes, exports, jobs and privileged actions with clearly separated data.
What is a noisy-neighbour problem?
A tenant’s workload consumes shared resources and degrades service for others. Capacity controls or workload separation may be needed even when data isolation is correct.
Bring the scope. We will help make it buildable.
Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.
Further reading
SaaS MVP features: complete one useful customer journey
Define a SaaS MVP around customer value, tenant boundaries and reliable operations. Decide which features to defer without leaving the first workflow incomplete.
Technical due diligence for a SaaS acquisition
Review SaaS isolation, recurring revenue dependencies, operating costs and integration risks. Connect technical evidence to the acquisition plan.
Stripe subscription integration: a SaaS delivery checklist
Connect Stripe billing events to an explicit access policy. Test subscription changes, failed payments, duplicate events and recovery before enabling live billing.