What is multi-tenant SaaS architecture?
A multi-tenant SaaS architecture serves multiple customers from shared application or infrastructure layers while preserving a trustworthy boundary around each customer’s data, workloads, and experience.
The shared part creates economic and operational leverage. The isolation part makes that leverage acceptable.
AWS distinguishes tenant isolation from ordinary authentication and authorization: a user can be authenticated and still access another tenant’s resource if the system fails to apply tenant context at the resource boundary.
Where should tenant context come from?
Resolve the tenant from a trusted identity or routing layer. Do not accept a tenant ID from a request body and treat it as authority.
A typical request carries:
- the authenticated subject;
- active tenant identifier;
- role and scoped permissions;
- subscription or service tier;
- region and data-residency attributes;
- correlation and trace identifiers.
Propagate this context through synchronous APIs, background jobs, events, caches, and data queries. If a queue message loses tenant context, the worker cannot safely decide which records it may process.
Which isolation model should you choose?
| Model | Isolation | Operational profile |
|---|---|---|
| Silo | Dedicated stack or resource per tenant | Strong boundary, highest fleet overhead |
| Pool | Shared resources with policy-based isolation | Efficient, demands consistent controls |
| Bridge | Dedicated high-risk layers plus shared services | Flexible, more routing complexity |
| Tiered | Isolation varies by plan or requirement | Commercially useful, must avoid policy drift |
The model can differ by layer. A tenant may share the application and queue while using a dedicated database or encryption key. Choose the boundary based on data sensitivity, compliance, performance, recovery needs, and the team’s ability to operate it.
Shared Compute
Context Injection (TenantID)
How do you isolate the data layer?
Pooled tables
Include a tenant key in every tenant-owned record and query. Use composite uniqueness rules that include the tenant. PostgreSQL row security policies can add a database-enforced boundary, but application code, migrations, elevated roles, exports, and maintenance paths still require review.
Schema per tenant
Schemas create clearer logical separation but increase migration and connection complexity as tenant count grows.
Database per tenant
Dedicated databases provide a strong operational boundary and easier tenant-specific backup or residency. They also create a fleet that must be provisioned, patched, migrated, observed, and recovered consistently.
Test isolation with negative cases
For every resource type, verify that a valid user from tenant A cannot read, modify, export, reference, or infer tenant B's resource. Run these tests against APIs, background workers, search indexes, object storage, caches, analytics, and support tooling.
How do you prevent noisy neighbors?
Isolation also protects availability. AWS SaaS guidance recommends throttling and scaling controls so one tenant cannot degrade another tenant’s experience.
Apply tenant-aware limits at several layers:
- API request and concurrency quotas;
- queue partitions and worker fairness;
- database connection, query, and workload limits;
- storage and export quotas;
- model-token and tool-call budgets;
- cache-key namespaces;
- per-tenant circuit breakers.
Measure saturation and latency by tenant and tier. Global averages hide a tenant consuming most of a shared pool.
What commonly leaks across tenant boundaries?
The primary database is not the only risk. Review:
- search and vector indexes;
- object-storage paths and signed URLs;
- cache keys;
- analytics events and dashboards;
- logs, traces, and error reports;
- exports and generated files;
- webhooks and integration credentials;
- model prompts, conversation memory, and evaluation samples;
- support impersonation and administrative tools.
Each system needs a tenant-aware namespace and access decision. Prefixing a key with a tenant ID is useful only if the requester cannot select another tenant’s prefix.
How should background work be designed?
Put tenant identity, operation identity, and idempotency data in every job. Workers should re-authorize the target resource rather than assume the producer was correct. Dead-letter queues must preserve tenant context so operators can investigate without mixing data.
For scheduled tasks across many tenants, create bounded tenant-level work units. This supports fair scheduling, retry isolation, cost attribution, and selective pause during an incident.
What does tenant-aware observability look like?
Every trace and metric should carry a privacy-safe tenant dimension. Teams need to answer:
- Which tenant experienced the failure?
- Was the problem isolated or platform-wide?
- Which shared dependency was saturated?
- Did a deployment affect one isolation model differently?
- Can support inspect the incident without viewing unnecessary customer data?
Avoid placing customer names or sensitive data in metric labels. Use stable internal identifiers and enforce access controls in the observability platform.
How do you operate schema changes safely?
Treat migrations as fleet operations:
- make changes backward compatible;
- deploy readers that understand old and new shapes;
- migrate in controlled batches;
- measure progress and tenant-level failures;
- switch writes only after compatibility is proven;
- retain a tested rollback or roll-forward path.
Dedicated databases and schemas require orchestration across many targets. Pooled tables reduce target count but increase the blast radius of a bad migration. Neither model removes operational risk.
A practical architecture review
Trace one request from edge to storage and one background job from queue to side effect. At every boundary, ask:
- Where did tenant context originate?
- Can the caller replace it?
- Which policy enforces the boundary?
- Is the cache, query, or object path tenant-scoped?
- Is usage limited fairly?
- Does the trace prove the decision?
- What happens if the dependency retries?
Multi-tenancy is not a database setting. It is a system-wide invariant.