Multi-tenant architecture: serving many companies safely
A SaaS product can serve many companies from a common platform, but sharing infrastructure creates decisions that a second login screen will not solve. Define the tenant boundary, enforce it across every data path and decide which resources may be shared. Capacity, recovery and customer requirements then guide the architecture.
A tenant is the customer or organizational boundary whose users and data belong together. It is not necessarily one person, one domain or one database. A company may need separate production and training tenants, while a consultant may be authorized to work across several customers.
Multi-tenancy can make common operations easier to manage, but the benefits depend on the design and operating model. Start with the product’s actual isolation and service requirements. The number of customer accounts alone does not prove that a system is ready for sustained load.
01Define what a tenant can see and control
Write down who belongs to a tenant, who can invite users and how a user changes their active organization. Separate tenant administrators from platform operators. A platform operator may need broad support tools, but ordinary company administrators should not inherit those powers because the interface looks similar.
Use an illustrative field-service product to clarify the boundary. A customer company owns its jobs and attachments. Its regional offices may share a tenant or require separate ones. A contractor serving two customers needs authorized membership in both, with an explicit context for each action.
Decide whether billing accounts and tenants are the same object. A parent organization may pay for several separate environments. Keeping the commercial relationship distinct from the authorization boundary avoids using a billing shortcut as an accidental access rule.
Document permitted cross-tenant workflows, such as a controlled transfer of a job or a platform support session. They need an explicit authorization model and audit trail. Treating every cross-tenant action as an exceptional database edit makes the boundary difficult to review.
Include lifecycle events in the definition: creation, suspension, merger, export and deletion. Determine what happens to user memberships, queued work and external integration credentials when a tenant is suspended. Disabling its sign-in page alone may leave background processing active.
02Choose sharing at each layer
| Pattern | Useful characteristic | Cost or complexity to examine |
|---|---|---|
| Shared application and shared data store | Common operation and efficient resource sharing | Enforcing every tenant boundary and managing contention |
| Shared application with separate databases | Stronger separation of data operations | Provisioning, migrations and fleet administration |
| Dedicated deployment per tenant | Independent infrastructure and configuration | Recurring cost and consistent updates |
| Hybrid deployment | Isolation adapted to specific tenant requirements | Routing, migration and maintaining supported variants |
Microsoft’s tenancy model guidance distinguishes tenants from deployments and describes shared, dedicated and mixed approaches. Different layers can have different isolation choices. A separate database does not require a separate copy of every frontend service.
List the drivers for each choice: data separation, performance, recovery, customer-managed keys, geographical requirements and operational capacity. Confirm requirements precisely. A customer asking for isolation might mean no shared database, a dedicated cloud account or simply a demonstrable authorization boundary.
Consider how you will move a customer between deployment groups. A routing registry, portable identifiers and a repeatable data migration process can support that transition. Designing a dedicated option without a transition plan may leave large customers trapped in the original shared environment.
Avoid customer-specific code forks unless there is a clear support model. Prefer configuration and explicit feature entitlements where appropriate. Every divergent release adds work to security fixes and schema migrations, which can erode the practical advantage of operating a common product.
03Enforce the boundary beyond sign-in
AWS’s tenant isolation guidance treats isolation as a distinct requirement from authentication and ordinary authorization. Identifying a user does not itself establish that a data operation is restricted to their tenant. The application needs a trusted tenant context and consistent enforcement.
Derive context from verified identity and membership information. A tenant identifier supplied in a request is an input to validate, not authority to access that company. Check object ownership and action permissions when reading, changing, deleting or exporting data.
Review caches, search indexes, object storage paths, generated downloads and message queues. A correct SQL filter cannot prevent leakage from a cache key that omits tenant identity. An export link should remain scoped and authorized, even if its filename or object identifier is difficult to guess.
For database enforcement, PostgreSQL documents row security policies and their bypass behavior. Table owners, superusers and roles with relevant bypass privileges require special attention. A policy is effective only when the runtime role and context actually cause it to apply.
Test context handling with connection pools and reused workers. Tenant information must not persist accidentally into a later request. Use a design that reliably establishes and clears the required context, then verify the behavior through the same execution paths used in production.
04Protect customers from noisy neighbors
A large tenant can consume shared CPU, database connections or queue capacity while other companies are doing ordinary work. Treat this as a workload management problem. Observe usage by tenant so an aggregate dashboard does not hide a small customer’s deteriorating experience.
Define limits for expensive activities such as exports, imports and attachment processing. Use fair scheduling where appropriate and separate long-running tasks from interactive requests. Increasing server capacity can help, but it does not explain which workload is consuming the new capacity.
Choose overload behavior deliberately. A limited export may be deferred with a clear status instead of retrying aggressively. Consider how user-triggered retries, integration retries and scheduled jobs interact. Several individually reasonable policies can amplify the same overload if no one reviews the combined behavior.
Measure response time, errors and queue delay for representative tenant sizes. Include bursty and uneven loads, not only evenly distributed requests. State the test conditions and service targets internally; avoid promising a particular number of customers without connecting it to their actual usage.
Use separate capacity or deployments for workloads that cannot reasonably coexist. This should follow evidence and requirements rather than an assumption that all enterprise customers need identical isolation. Keep the common operating and release process intact where possible.
05Automate onboarding and version changes
Tenant provisioning should create the required records and resources consistently, with a visible completion state. Make retries safe so a partial failure does not create duplicate billing accounts or abandoned databases. Record what was created and how the operation can be completed or reversed.
Set configuration through supported controls rather than manual changes to production tables. Validate required integration credentials and distinguish an incomplete connection from an active customer. A tenant should not appear ready simply because its organization record exists.
Plan schema migrations for the chosen topology. One shared database has a different migration workflow from a fleet of separate databases. Track the version of each deployment and avoid treating a partly updated fleet as though all customers are running the same state.
Use compatible application changes when old and new versions may operate together. Release feature entitlements only when dependencies are ready. A flag can control exposure, but it cannot repair an incompatible database write or remove data already created in a new format.
Test suspension and offboarding as seriously as creation. Revoke relevant memberships and integrations, stop or handle pending jobs, and apply the agreed data retention process. Keep the record needed for accountability without retaining every customer file indefinitely.
Connect these tasks to the delivery plan rather than postponing them until customer growth exposes a gap. The SaaS development planning guide provides the wider product context, while the database choice comparison helps frame storage requirements.
06Design tenant recovery and support operations
Ask whether you can recover one tenant without undoing other tenants’ newer work. In a shared store, restoring the whole database is often different from recovering one company’s records. Define the extraction, reconciliation and validation steps needed for the business recovery scenario.
Include related data: attachments, search indexes, external identifiers and integration state. A restored job record with a missing document or duplicate outbound transaction may not be a usable recovery. Have the tenant owner verify representative workflows after the technical operation.
Provide support access through an auditable, time-bound process. Record the tenant context, reason and actions, and limit data visibility to the task. Giving every support worker an unrestricted platform account makes routine troubleshooting harder to govern.
Monitor isolation failures and tenant-specific service issues as actionable events. Identify who investigates and how affected customers can be determined. An aggregate success rate can look healthy while a particular tenant repeatedly fails because of its configuration or data size.
Before expanding the customer base, rehearse a tenant migration, a failed onboarding, an abusive workload and a restoration. Record limitations and ownership. These exercises reveal whether the design is a manageable service, rather than a collection of customer records in a shared database.
07Questions about multi-tenant systems
Is multi-tenancy the same as a shared database?
No. It describes serving distinct tenants from a product or platform. Application, data and infrastructure layers can use different sharing choices, including dedicated resources.
Is one tenant always one company?
Not necessarily. Define the boundary around access and operating requirements. A company may need several environments, while billing can group several tenants.
Does successful authentication prove tenant isolation?
No. Every operation must enforce the authorized tenant context, including exports, files, caches and background jobs.
Should every tenant have its own database?
Compare data separation, recovery and workload requirements with the cost of provisioning and managing a database fleet. There is no universally best option.
Can row-level security do all the work?
It can strengthen database enforcement, but roles and bypass behavior matter. Other storage and application paths still require isolation and testing.
What is a noisy neighbor?
A tenant whose resource consumption degrades other tenants’ service. Observe tenant-level usage and use appropriate limits, scheduling and capacity separation.
When should a tenant move to a dedicated deployment?
When a substantiated requirement or workload justifies it and the product has a supported migration and operating process. Customer size alone is not a complete criterion.