Multi-Tenant Architecture for SaaS: Concepts and Decisions

Multi-tenant architecture allows serving multiple organizations with the same platform while keeping each client's data and permissions isolated. The central decision is not just where the data resides. It is how the tenant context tracks identity, queries, files, queues, cache, logs, and administrative tasks without opening cross-access pathways.

Direct answer: which model to choose

Use the pool model when efficiency and shared operation are priorities and the domain accepts well-tested granular policies. Use silo when isolation, contractual requirements, or risk justify dedicated resources. The bridge model combines elements: for example, a shared application with a separate schema or database. The choice may vary by plan or client sensitivity.

AWS emphasizes that role authentication and authorization are not enough for isolation. A user may be authenticated and authorized to use a feature but can still access another tenant's resources if the organizational context is not applied in each operation.

Model identity and belonging first

Separate user from organization. A person can belong to more than one tenant and have a different role in each. A common model includes organizations, memberships, roles, and domain entities with organization_id. The active tenant must be resolved on the server from a valid association, never accepted solely from a field sent by the browser.

Tokens can carry context, but changes in association and revocation need to be considered. For sensitive operations, confirm current belonging on the server or in the database. Administrative keys should not be exposed to the client.

RLS as defense in depth

In PostgreSQL/Supabase, Row Level Security applies policies to each access to the table. The official documentation recommends enabling RLS on exposed schema tables. In a multi-tenant application, policies typically relate the row to the tenant and check the user's association.

RLS does not replace API design, validation, or testing. It creates an additional barrier in case a query forgets a filter. Indexes on the columns used by the policies are important to prevent security from becoming a bottleneck. Operations with service_role or privileges that ignore RLS require separate pathways, logging, and more rigorous review.

The context needs to traverse the entire architecture

• Database: all entities belonging to the client have a tenant key.
• Storage: paths and policies include organization, not just user.
• Cache: the key contains tenant and relevant permissions.
• Queues: each message logs tenant and operation identity.
• Search: indexes and filters preserve the organizational limit.
• Logs: tenant appears for investigation, without exposing undue data.
• Metrics: consumption is attributed to the tenant for cost and limits.
• Administration: privileged actions have reason, actor, and audit trail.

A leak can occur outside the database. A shared cache with an incomplete key or an asynchronous job without context can return correct data to the wrong client.

Testing strategy

Create at least two tenants in automated tests. For each query and mutation, prove the allowed access and also the cross-denial. Test listing, searching by known ID, updating, deleting, files, exports, jobs, and administrative routes.

Include scenarios of tenant change, revoked invitation, user without association, manipulated IDs, and attempts to use resources created by another organization. In RLS, test the policies directly in the database with roles equivalent to those in the application. Backups and restoration also need to preserve belonging.

When to migrate from pool to bridge or silo

Do not migrate just for abstract growth. Look for signs: contractual requirements, data residency, clients with disproportionate load, need for a dedicated window, isolated recovery, or customization that threatens the shared model. Design early identifiers and provisioning automation that allow moving a tenant without rewriting the domain.

Review checklist

• Explicit tenant in entities, files, queues, and caches.
• Belonging validated on the server and in the database.
• RLS enabled and tested on exposed tables.
• Indexes compatible with filters and policies.
• No privileged keys in the browser.
• Negative tests between two or more tenants.
• Logs of administrative actions and critical changes.
• Metrics and limits by organization.
• Backup and restoration tested.
• Documented plan to move or isolate tenants.

Primary sources

• AWS: SaaS Tenant Isolation Strategies
• AWS: Tenant isolation in SaaS
• AWS: Guidance for Multi-Tenant Architectures
• Supabase: Row Level Security

See also the precautions for security and LGPD in SaaS and our approach to SaaS platform development.