Define the tenant boundary before choosing a database pattern. Decide who and what belongs to a tenant, how context is established, which resources require pooled, siloed or hybrid isolation, and how provisioning, access, customisation, billing, observability, migration and deletion will work. Test isolation as a security property throughout the stack.
This is a core SaaS development architecture decision supported by web application development and automation for lifecycle operations. Adding a tenant_id column alone does not create a safe SaaS platform.
AWS states that tenant isolation is separate from general authentication and authorisation because an authenticated user could still access another tenant's resources without explicit isolation controls Source: AWS. Make tenant context a first-class security boundary.
Define what a tenant is
Write the business definition: company, department, franchise, workspace, household, project or another boundary. Clarify whether a user can belong to several tenants and switch between them.
Define:
- tenant identifier and lifecycle
- membership and roles
- parent and child tenants
- shared users and service accounts
- reseller or support access
- data ownership
- region and residency
- contract and billing account
Classify resources by isolation need
Inventory data, compute, queues, caches, files, search indexes, logs, secrets, model context, analytics and third-party integrations. Rate impact if another tenant can read, change, infer, delay or delete the resource.
Choose isolation per resource. A shared compute pool may be acceptable while sensitive document storage uses dedicated keys or accounts. Some premium or regulated customers may need a stronger tier.
AWS describes silo, pool, bridge and tier-based isolation strategies and notes that the right approach depends on domain, compliance, deployment model and technology Source: AWS. Avoid one universal answer.
Establish tenant context securely
Derive tenant context from trusted identity and server-side membership, not from an unchecked request field. Validate it at every service boundary and background job.
Use short-lived credentials and policies scoped to the tenant where the platform permits. Propagate context through queues, scheduled tasks and event messages without allowing callers to substitute another identifier.
Log the acting user, tenant, action and authorised resource. Protect logs from leaking another tenant's data.
Choose the data pattern
Common options include shared tables with tenant keys, separate schemas, separate databases and hybrid models. Evaluate:
- isolation strength
- query and migration complexity
- backup and restore granularity
- noisy-neighbour risk
- analytics needs
- residency requirements
- cost and operational scale
- per-tenant encryption
Enforce tenant predicates through shared libraries, database policy or scoped credentials rather than relying on every developer to remember a filter.
Design control and data planes
Separate tenant management from tenant workload where useful. The control plane can handle onboarding, configuration, plan, region, identity, keys and provisioning. The data plane handles business requests with established tenant context.
Protect control-plane actions strongly because they can affect many tenants. Require audit, approval and idempotency for provisioning, deletion, key rotation and migration.
Make provisioning asynchronous and observable. A tenant should not appear active while required storage or permissions remain incomplete.
Plan customisation without forks
Define which settings tenants can change: branding, workflow, fields, roles, integrations, retention or policy. Store configuration as data with validation and versioning.
Avoid customer-specific code branches that prevent consistent releases. Use feature flags and entitlements with explicit ownership and expiry.
Test combinations, not only individual flags. A feature enabled for one plan should not expose data or actions from another.
Control noisy neighbours
Set per-tenant quotas, concurrency, queue priority, storage, API and export limits. Monitor resource use and reject or defer work predictably when limits are reached.
Use bulkheads so one tenant's import or report cannot exhaust the whole service. Plan premium capacity or isolation tiers where the commercial model supports them.
Include abuse and runaway automation in the threat model, not only normal peak load.
Design tenant-aware observability
Measure availability, latency, errors, queue age, cost and usage per tenant while preserving privacy. Operators need to find one tenant's incident without viewing unnecessary business data.
Add tenant context to traces and metrics using bounded, secure identifiers. Avoid high-cardinality labels that overwhelm monitoring systems.
Create service objectives for the platform and important tenant tiers. Alert on cross-tenant signals and isolation-policy failures at the highest severity.
Plan billing and entitlements
Define the billable tenant, plan, usage units, limits, overages, trials, credits and suspension behaviour. Keep billing status separate from data deletion.
Entitlements should be enforceable server-side and auditable. Decide what happens when a plan changes during a long-running job or when metering is delayed.
Reconcile usage records and provide customer-visible explanations where usage billing applies.
Design lifecycle operations
Automate tenant creation, invitation, region selection, configuration, export, suspension, reactivation and deletion. Make operations idempotent and resumable.
Define retention after cancellation and how backups expire. Confirm deletion across search, files, analytics and third-party processors.
Support safe tenant-level backup and restore where the contract requires it. A full shared-database restore should not overwrite every other tenant to recover one record.
Test isolation continuously
Create automated negative tests that attempt cross-tenant reads, writes, searches, exports, file access, cache use, background jobs and administration.
Use separate tenant fixtures and randomised identifiers. Test support impersonation, invitation links, stale sessions and user membership changes.
Add architecture review and penetration testing proportional to risk. Treat any cross-tenant exposure as a major incident even when the data seems unimportant.
Plan the migration
Inventory existing customers, identifiers, duplicate records, ownership and integrations. Assign each record to a tenant with explicit reconciliation.
Backfill tenant context in stages, run shadow validation and prevent new unscoped data. Pilot low-risk customers, monitor, and keep a tested rollback.
Reconcile record counts, ownership, permissions and integration behaviour before and after every migration wave.
If your business cannot prove which tenant owns an existing record, resolve the ambiguity before moving it into a shared production model.
My take: isolation is an invariant
My take is that every feature should preserve one invariant: a request may act only within the established tenant context unless a narrowly controlled cross-tenant role is explicitly authorised.
Encode that invariant in infrastructure, libraries, policies, tests and review. Documentation alone will not withstand years of feature growth.
Frequently asked questions
Is a shared database always less secure?
Not automatically. Security depends on correctly enforced isolation, configuration and operations. Dedicated patterns can offer stronger boundaries but add complexity and cost.
Can one user belong to several tenants?
Yes, if the identity, session, switching, role and audit model handles membership explicitly and never carries stale tenant context.
Should enterprise tenants receive separate infrastructure?
Only when risk, compliance, performance or commercial requirements justify it. Hybrid and tier-based approaches are common.
How should support access work?
Use time-limited, approved, audited access with a stated tenant and purpose. Avoid permanent broad production access.
Design multi-tenancy before migrating data
If you need an isolation and migration architecture, get in touch for SaaS development, web application development and automation.
Related guides
For further background, read our cms vs custom development and website maintenance costs. The user journey glossary explains the terminology used in those guides.