Design pooled, schema-per-tenant and siloed isolation, with per-tenant encryption keys and a safe path to move tenants between tiers — without slowing delivery.
Design targets · not measured results from past client work
Design target: cryptographic tenant boundaries built to eliminate cross-tenant data exposure across all isolation tiers.
Design target: isolation that holds across pooled, schema-segmented, and sandboxed deployment modes.
Design target: automated onboarding covering schema creation, KMS key provisioning, and RBAC wiring.
Design target: CDC-based tenant elevation from pooled to isolated sandboxes without service interruption.
Multi-tenant SaaS architecture is a design in which one application serves many customers, called tenants, while keeping each tenant's data, performance and configuration separate. Tenants can share infrastructure, get dedicated resources, or sit somewhere in between. The right choice depends on risk, cost, compliance and how much isolation your largest customers need.
Tenants share tables and compute. A tenant ID on every row, enforced by row-level security, keeps their data apart. Lowest cost per tenant.
One database schema per tenant inside a shared cluster. A middle path between pooled and siloed; some teams call it the bridge model.
Dedicated database, compute and encryption keys per tenant. Used when contracts or regulation call for physical separation.
Each model is an established industry pattern, designed to support zero-downtime customer migration between tiers as compliance requirements evolve.
Shared schema architecture with tenant context set at the database session level. PostgreSQL RLS policies filter every query by tenant, so the application role only sees its own tenant's rows. Superusers and bypass roles sit outside RLS, so access to them is tightly restricted.
Each tenant receives an isolated database schema namespace within a shared cluster. Tenant-scoped migrations, independent index tuning, and schema versioning with a smaller cross-tenant blast radius — a good fit for regulated mid-market SaaS customers.
Dedicated compute, database, and networking resources per enterprise tenant. Physical isolation at every stack layer — separate VPC, separate RDS cluster, separate KMS key hierarchy. Often required by customers in healthcare, government and financial services with strict residency or contractual isolation requirements.
The same three tenants, placed in each model. Most platforms mix tiers: small tenants pooled, regulated tenants in their own schema, a few enterprise tenants siloed.
Illustrative diagram. AWS calls these silo, pool and bridge; many teams use "bridge" for schema-per-tenant.
Most platforms end up mixing tiers: small tenants pooled, regulated tenants in their own schema, a few enterprise tenants siloed.
| Model | Isolation strength | Cost per tenant | Operational effort | Best for | Main risk |
|---|---|---|---|---|---|
| Pooled with RLS | Logical. Depends on policies being correct and applied on every table. | Lowest | Lowest. One schema to migrate and monitor. | Many small and mid-size tenants; fast onboarding. | A missing policy, a role that bypasses RLS, or one heavy tenant affects everyone. |
| Schema-per-tenant | Stronger logical boundary. Separate objects per tenant. | Medium | Higher. Migrations run per schema and the catalogue grows with tenant count. | Regulated mid-market tenants; per-tenant tuning and restore. | Migration time and catalogue size grow with the number of tenants. |
| Siloed | Physical. Separate database, compute and keys. | Highest | Highest. Many stacks to deploy, patch and monitor. | Enterprise tenants with strict residency or contractual isolation. | Cost and fleet-management overhead. |
AWS describes three models: silo, pool and bridge, where bridge mixes silo and pool across different components. Many teams use "bridge" for schema-per-tenant. See the references below.
Core engineering building blocks included in every multi-tenant engagement.
Tenant identity extracted from JWT, header, or mTLS certificate at the edge and propagated as session context through every service call. Envoy proxy sidecars help carry that context consistently across services.
Customer-managed encryption keys (CMEK) via AWS KMS or HashiCorp Vault. Every tenant's data encrypted under their own key hierarchy — key rotation, revocation, and bring-your-own-key (BYOK) fully supported.
Per-tenant token bucket rate limiting enforced at the API gateway and database query layers. Redis Cluster tracks real-time consumption; Envoy Ratelimit blocks burst spikes before they affect other tenants.
Promote tenants from pooled to schema-isolated to fully sandboxed tiers without service interruption. Debezium CDC streams data in real-time while Kafka Replay ensures zero-loss consistency before Envoy route shifts cutover traffic.
Row-level security is a strong safety net, but only when it is set up and tested properly.
-- Every tenant table carries tenant_id
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.tenant_id', true)::uuid);
-- Per request, inside the transaction:
SET LOCAL app.tenant_id = '<tenant uuid>';Superusers and roles with BYPASSRLS skip row-level security, and table owners skip it unless FORCE is set, so run the application as a least-privileged role. Unique and foreign-key checks also bypass it, so include tenant_id in those constraints.
The capabilities that turn a working multi-tenant core into something enterprise buyers can approve.
A central record maps each tenant to its tier, database or schema, region and encryption key. Requests resolve the tenant first, so a growing customer can later move to a dedicated database without changing application code.
Composite indexes that start with tenant_id, tenant-scoped unique constraints and tenant-aware foreign keys keep queries fast and stop one tenant from affecting another tenant's constraint checks.
Expand, backfill, contract: add the new structure, copy data in batches per tenant, switch reads and writes, then remove the old structure. Each step can be reversed, and each tenant can move on its own schedule.
Per-tenant single sign-on and MFA policies, role mappings and audit trails, so each customer can connect its own identity provider.
Per-tenant data export, verified deletion across databases, caches, queues and object storage, and tenant-level restore into a separate resource instead of over live data.
Resource tags, usage metering and per-tenant quotas show which tenants cost what and where noisy-neighbour limits are needed.
Deployed isolation stack with real tenant context injection — pooled RLS, schema segmentation, and isolated sandbox tiers all running concurrently on AWS or GCP.
Real-time dashboard showing per-tenant key rotation status, encryption health, provisioning latency, and noisy-neighbour throttle metrics across all active tenants.
Full IaC repository for all three isolation tiers, plus an automated test matrix validating cross-tenant data leakage, KMS boundary enforcement, and zero-downtime elevation paths.
Six questions to ask any firm, including us, before you commit.
Ask which model they would use for each customer tier, and why. Look for reasoning based on risk, cost and compliance, and a plan for moving tenants between tiers.
Ask how they test that tenants cannot see each other's data. Look for automated cross-tenant tests that cover databases, caches, queues, files and search.
Ask how one tenant's load is kept from slowing the others. Look for per-tenant limits, quotas and monitoring.
Ask how they change the schema and move a tenant between tiers. Look for stepwise, reversible migrations and rehearsed rollbacks.
Ask what you own at the end. Look for code, infrastructure as code, runbooks and training handed over, with acceptance criteria agreed up front.
Ask for architecture diagrams, test results and references you can verify. Treat unsourced numbers with care.
It is a design where one application serves many customers, called tenants. Each tenant's data and settings are kept separate, either logically (for example with a tenant ID and row-level security) or physically (separate databases). Sharing infrastructure lowers cost per tenant; stronger separation lowers risk.
Pooled tenants share tables and compute, separated by a tenant ID. Schema-per-tenant gives each tenant its own schema inside a shared database. Siloed gives each tenant dedicated resources such as its own database and compute. AWS uses the terms pool, silo and bridge, where bridge mixes pooled and siloed components.
It is a strong safety net, not the whole answer. Superusers and roles with BYPASSRLS skip it, table owners skip it unless FORCE ROW LEVEL SECURITY is set, and unique and foreign-key checks bypass it. Use it with a least-privileged application role, tenant context set per transaction, authorization checks in the application, and automated cross-tenant tests. For the highest-risk tenants, use separate databases.
Resolve the tenant through a registry so routing can change without code changes. Copy the tenant's data to the new database while keeping it in sync with change data capture, verify it, then switch the route and keep a rollback until the new setup is validated. The aim is little or no downtime, but the result depends on workload and should be tested before a live move.
Make the tenant a dimension in rate limiting: per-tenant limits at the API and database layers, bounded use of shared pools, queues and workers, and per-tenant metrics. Tenants that keep exceeding their share can be moved to dedicated resources.
Deletion has to cover every store: databases, caches, queues, search indexes, object storage and backups, following your retention policy. For restore, bring a single tenant's data back into a separate resource and then reconcile, rather than restoring over live data.
It depends on your customers. Many small tenants usually fit pooled. Regulated mid-market tenants often fit schema-per-tenant. A few enterprise tenants with strict contracts may need siloed resources. Most platforms mix tiers, which is why the path between tiers matters as much as the first choice.
Last reviewed: October 2026
Book a technical audit with our principal architects to design your tenant isolation architecture.