Define the forbidden result before choosing the database pattern
SaaS tenant isolation requirements should state which customer boundary each resource belongs to, where that boundary is enforced, which cross-tenant actions are intentionally allowed, and what evidence proves every other action fails. A tenant ID column, a separate database, or a login screen is not a complete isolation design.
Begin with two real tenant profiles and one high-impact workflow. Trace reads, writes, files, cached responses, searches, queued jobs, analytics, exports, logs, backups, restores, and support access. For each step, write an allowed case and a forbidden cross-tenant case. That turns “keep customer data separate” into requirements engineering can implement and QA can reject.
This guide is narrower than the existing single-tenant vs multi-tenant SaaS decision guide. That article helps choose an operating model; this one defines how to make the chosen boundary enforceable and testable.
Write one isolation contract per resource and action
Record the actor, verified tenant context, resource owner, requested action, policy decision, enforcement point, allowed response, forbidden response, logged evidence, and recovery owner. Treat intentionally shared resources—such as public templates, platform notices, or cross-organization collaboration—as explicit exceptions with their own policy, not as holes in the default boundary.
AWS describes isolation as foundational and distinct from authentication and authorization in its SaaS isolation guidance. A valid user can still cross a tenant boundary if a resource lookup, background job, cache key, or operator tool accepts an unverified tenant selector.
Inventory every place tenant-owned state can travel
Classify relational rows, documents, uploaded files, object storage, cache entries, search indexes, vectors, queues, events, scheduled jobs, data-warehouse records, product analytics, support logs, notifications, webhooks, exports, backups, and temporary processing files. For each, name the owning tenant, intentionally shared scope, lifecycle, encryption or credential boundary, and deletion and restore behavior.
New paths create risk when the inventory is static. Add a design and release check requiring every new table, bucket prefix, index, topic, metric, log field, export, and administrative query to be classified. The OWASP Multi-Tenant Security Cheat Sheet specifically warns against shared cache keys, trusting client-supplied tenant IDs, unscoped queries, and treating a tenant identifier in a queued message as authorization proof.
Choose the isolation model per resource, not by slogan
| Model | Useful when | Proof still required |
|---|---|---|
| Pooled | Efficiency and uniform operations matter, with strong logical policy | Tenant context, policy coverage, negative tests, quotas, and blast-radius controls |
| Partitioned | A shared service can separate schemas, partitions, indexes, keys, or storage prefixes | Correct routing, credentials, migration, rebalancing, and inventory coverage |
| Dedicated | Contract, risk, residency, workload, or recovery needs justify separate resources | Shared control-plane safety, fleet consistency, support access, and decommissioning |
| Hybrid | Different resources or customer tiers have different pressures | A visible placement policy and safe movement between classes |
AWS calls these pool, silo, and bridge patterns and notes that all can be valid depending on business, regulatory, and legacy constraints in its SaaS partitioning model guidance. Microsoft likewise recommends choosing tenancy models for different solution parts, continuously testing isolation, and planning for noisy-neighbor behavior in its multitenancy checklist. Avoid promising that one pattern is universally “enterprise.”
Derive tenant context once, then enforce it at every boundary
Define how a request becomes associated with a tenant: verified session membership, service credential, delegated administrator, signed integration context, or another server-trusted source. Routes, subdomains, form fields, headers, and object IDs can help select a tenant, but they do not prove access by themselves.
Carry the verified context through service calls and asynchronous work, then reauthorize the actual action close to the protected resource. Scope object lookups, uniqueness rules, filenames, cache keys, search filters, rate limits, metrics, and audit events. The existing SaaS permissions requirements checklist helps define roles and actions; isolation adds the customer boundary those permissions must never escape.
Database controls can provide defense in depth. PostgreSQL row security, for example, can restrict which rows normal queries return or modify, but table owners usually bypass it and superusers or roles with BYPASSRLS always do. The PostgreSQL documentation is a reminder to test with the deployed request role and not mistake one database feature for an end-to-end architecture.
Make forbidden cross-tenant behavior a release gate
Create Tenant A and Tenant B with overlapping names, different roles, files, records, integrations, and workload profiles. As Tenant B, attempt to read, enumerate, update, attach, delete, search, export, cache-hit, subscribe to, or trigger work for Tenant A. Repeat with stale membership, guessed identifiers, direct service calls, reused database connections, delayed events, replayed messages, and support credentials.
Test the allowed side too. Overly broad denial can break a legitimate shared template, platform administrator, multi-tenant user, partner collaboration, or authorized migration. For every matrix row, state the expected status, returned shape, side effects, audit event, alert behavior, and information that must not leak through errors, counts, timing, or logs.
AWS recommends tests that inject altered tenant context, exercise shared enforcement libraries, simulate noisy tenants, and verify lifecycle changes in its multi-tenant testing guidance. Keep those tests versioned with the product and run them when schemas, policies, integrations, caching, search, or deployment topology changes.
Use this tenant-isolation planning worksheet
- Tenant: What customer, organization, workspace, or business boundary does it represent?
- Actors: Which users, services, operators, and delegated administrators can enter this boundary?
- Resources: Where does tenant-owned or tenant-derived state exist, including secondary paths?
- Class: Is each resource pooled, partitioned, dedicated, intentionally shared, or hybrid—and why?
- Context: Where is tenant context established, propagated, checked, and logged?
- Operations: How do support, migrations, exports, deletion, backup, and restore preserve the boundary?
- Pressure: What triggers a tenant or resource to move to a different isolation class?
- Evidence: Which positive, negative, load, and recovery tests block release?
Scope one high-risk vertical slice before redesigning the whole platform: request authentication, policy enforcement, one tenant-owned record, one file, one background job, one support action, and their negative tests. If a mature platform already provides the needed controls, use them. If the product boundary is distinctive, a scoped SaaS platform development engagement can turn the contract into a maintainable implementation plan.
SaaS tenant isolation requirements FAQ
What should SaaS tenant isolation requirements include?
Include the tenant definition, trustworthy tenant context, resource inventory, isolation class per resource, data and object ownership, authorization enforcement, cache and search scoping, asynchronous work, integrations, logs and analytics, exports, backups and restores, platform administration, noisy-neighbor controls, monitoring, incident response, migration triggers, and automated positive and negative acceptance tests.
Is row-level security enough for tenant isolation?
No. Row-level security can strengthen a shared relational database boundary, but tenant-owned data may also exist in object storage, caches, search indexes, queues, analytics systems, exports, logs, and backups. Database owners, superusers, migrations, support tools, and background workers also require deliberate controls and tests.
Does every SaaS customer need a separate database?
No. Shared, partitioned, dedicated, and hybrid models can all be valid. Choose per resource from the threat model, customer commitments, residency needs, recovery granularity, workload behavior, operational capacity, and cost. Dedicated infrastructure does not remove the need for tenant-aware identity, authorization, operations, and evidence.
How should tenant isolation be tested?
Provision at least two test tenants and attempt forbidden reads, writes, searches, downloads, cache hits, queued jobs, exports, restores, and administrative actions across the boundary. Exercise the same roles, connection pools, tokens, background workers, indexes, and deployment configuration used in production, then make the negative suite a release gate.