Multi-Tenancy Architecture
A multi-tenant system serves many customers (tenants) from shared infrastructure while keeping each tenant's data and load isolated. The central tension is isolation vs efficiency: strong isolation costs money and operational overhead; pooling resources is cheap but risks data leaks and noisy neighbors.
Every multi-tenant design answers two questions per layer (compute, storage, network): how strongly are tenants isolated, and how is a request reliably attributed to the right tenant? Getting tenant identity wrong is a security incident — cross-tenant data exposure is the cardinal sin of SaaS. Source: compiled from SaaS multi-tenancy patterns
Isolation models
| Model | What | Isolation | Cost / efficiency |
|---|---|---|---|
| Silo | Dedicated stack per tenant (own DB/compute) | Strongest; blast radius = 1 tenant | Expensive; poor density |
| Pool | All tenants share infra + a tenant-id column | Weakest; relies on app correctness | Cheapest; best density |
| Bridge | Hybrid — shared compute, isolated storage (or vice versa) | Medium | Balanced |
Most SaaS starts pooled for efficiency and silos the largest/most-regulated tenants (a tiered approach). The model can differ per layer: pooled compute with siloed databases is common.
Mechanisms
- Tenant context — every request carries a verified tenant id, resolved once at the gateway (from token/subdomain/key) and propagated downstream. All data access is scoped by it.
- Data isolation — separate databases (silo), separate schemas (bridge), or a
tenant_idfilter enforced at the query layer / via row-level security (pool). RLS or a repository that cannot issue an unscoped query is the safety net. - Tenant routing — map tenant → shard/cell (same key-to-owner mapping as Sharding and Partitioning Architecture); "cell-based" architectures put groups of tenants in isolated cells to bound blast radius.
- Per-tenant limits — rate limits and quotas keyed by tenant prevent one from starving others.
The noisy-neighbor problem
In pooled resources, one tenant's spike (a heavy query, a traffic burst) degrades everyone. Mitigations: per-tenant rate limits and quotas, resource isolation (microVMs/containers per tenant for compute), fair-scheduling, and usage-based throttling. Strong compute isolation is exactly why agent platforms run untrusted tenant code in per-tenant sandboxes.
Design implications
- Default-deny on tenant scope. The data layer should make an unscoped query impossible, not merely discouraged.
- Blast radius is a design output. Silo/cell limits how many tenants one failure or bad deploy can hit.
- Tiering is normal. Mix models by tenant size/compliance rather than forcing one everywhere.
- Observe per tenant. Attribute cost, latency, and errors per tenant or you cannot find the noisy neighbor.
Kevin's Dedalus platform is multi-tenant agent infra: DAuth resolves tenant auth and credential boundaries, the API Backend scopes data per tenant, and microVM workspaces give per-tenant compute isolation so one tenant's agent code cannot touch another's.
Timeline
- 2026-06-02 | Page created. Captured the isolation-vs-efficiency tension, the silo/pool/bridge models, mechanisms (tenant context, data isolation/RLS, cell routing, per-tenant limits), the noisy-neighbor problem, and default-deny/blast-radius/tiering implications, grounded in Dedalus. Source: compiled from SaaS multi-tenancy patterns
- 2026-07-01 | Linked DAuth as the Dedalus tenant-auth and credential-boundary primitive for hosted MCP servers. Source: Dedalus Auth