A CTO choosing a multi-tenant architecture is deciding what customers may share, what they must never share, and how that promise will hold during a bad day. A separate database can reduce one class of risk, but it cannot by itself stop a mis-scoped API, cache entry, background job, support export, or operator action. Conversely, a pooled system is not automatically unsafe if tenant scope is enforced and tested across those paths. AWS SaaS Lens makes the same distinction between authentication and tenant isolation.
This guide is a decision memo for a B2B SaaS product team. It compares pooled, bridge, and siloed choices without assuming that one model should cover every tenant or every component. The companion architecture guide explains the underlying patterns; here the focus is what evidence a CTO should require before choosing and changing one.
Start with the tenant promise, not the database
Define a tenant in the product contract: an organization, legal entity, customer account, or something else. Record whether a user can belong to several tenants, who may switch context, and whether a reseller or support operator can act across them. Then list each protected resource: records, files, search indexes, cache entries, jobs, audit logs, backups, model context, and exports. “Tenant ID” is a field; isolation is the enforced behavior of the whole system.
| Decision question | Evidence to collect | Reason it changes the design |
|---|---|---|
| Which data must be separated by policy, contract, or residency? | Written requirements tied to records, regions, retention, and support access. | May require dedicated storage or deployment for a subset of tenants. |
| How uneven is tenant demand? | Representative peak reads, writes, jobs, storage growth, and recovery objectives. | Shows whether shared capacity needs quotas, queues, or dedicated stamps. |
| What can the team operate repeatedly? | Provisioning, schema migration, backup/restore, incident, and cost-allocation rehearsals. | Dedicated resources increase the number of units to deploy and support. |
| What must change later? | Expected tenant count, tier commitments, integration needs, and a migration trigger. | A design without a tenant-move path can lock in an early compromise. |
Compare pooled, bridge, and siloed boundaries
| Model | When it may fit | Control and operating trade-off |
|---|---|---|
| Pool: shared application and storage | Many similar tenants with a common release path and no requirement for dedicated storage. | Enforce tenant scope in shared policy and data access; test every query, cache, queue, and export path. Set per-tenant capacity limits and attribution. |
| Bridge: shared control plane with selected dedicated components | Most tenants can share, while some need dedicated data, compute, region, or performance capacity. | Keep tenant routing, identity, deployments, and recovery rules explicit; operating two shapes costs more than either shape alone. |
| Silo: dedicated deployment or resources per tenant | A contract, regulatory boundary, workload profile, or recovery requirement justifies separation. | Resource separation reduces some blast radius but does not replace authorization; provisioning, migrations, monitoring, and patching multiply. |
These are patterns, not product tiers or security guarantees. Microsoft’s tenancy model guidance weighs isolation against scale and operational cost. Its storage guidance explicitly allows a mixed design, such as a shared database for most tenants and a dedicated stamp for tenants with unusual requirements.
Make a representative decision before choosing a pattern
Consider a hypothetical B2B workflow product with many small organizations and one prospective customer that requires a separate data region and a tighter restoration objective. The team could use a pooled application and database for the ordinary cohort, with centrally enforced tenant policies, per-tenant quotas, and tenant-aware backups. It might place the exceptional customer on a dedicated data stamp if the documented requirements cannot be met in the pool. That is a design example, not an Edilec customer case or a performance result.
The CTO should reject that proposal if the team cannot demonstrate tenant-scoped authorization at the write service, preserve context through jobs and exports, restore one tenant without exposing another, or operate both deployment shapes with the available staff. A dedicated database would not cure those missing controls. AWS’s cross-tenant access guidance illustrates how even a shared serverless function needs tenant-scoped access to downstream resources.
Require an isolation test, not a diagram-only review
Build the test matrix with two real test tenants, distinct permissions, and harmless synthetic records. The expected result is denial or tenant-scoped output; a passing test records which enforcement point made that decision. Do not use client data in a demo.
| Failure case | Expected behavior | Evidence to retain |
|---|---|---|
| Tenant A changes a URL or object ID to Tenant B’s record. | The service denies the read and write before returning or mutating B’s data. | Actor, selected tenant, target, policy version, deny reason, and a regression test. |
| A role is revoked while a queued job is delayed. | The job uses an authorized current scope or stops; it does not inherit stale privilege silently. | Job identity, effective permission time, decision, and correction path. |
| A cache key or export is built without tenant context. | The result cannot be reused or delivered across tenants. | Cache/export key design, negative test, and owning service. |
| One tenant saturates a worker or query pool. | Other tenants retain the agreed service behavior or receive a bounded, explained degradation. | Per-tenant usage, queue age, limits, and recovery action. |
| A restore or tenant move is rehearsed. | Records, identifiers, permissions, and audit history reconcile before cutover. | Restore result, discrepancy log, rollback trigger, and sign-off owner. |
OWASP’s multi-tenant security guidance calls for tenant-aware authorization and testing across shared resources. Treat that as a security baseline, then add the product-specific capacity and support promises that matter to your customers.
Keep the migration path and operating cost visible
A decision that works for the first ten tenants can fail at the hundredth because the expensive part is often provisioning, schema change, restore, support access, or noisy-neighbor control. Give every tenant a stable identifier independent of database location. Put tenant-to-resource routing behind an owned service. Track cost and saturation by tenant or cohort so a move is triggered by evidence rather than a sales label.
Before moving a tenant between pool and silo, rehearse an export, validation, cutover, and rollback with synthetic data. Define where writes are authoritative during migration, how delayed jobs are handled, and how checksums or business totals reconcile. Keep the old path until the new route has passed normal and adverse traffic. Do not claim a migration is complete merely because the records copied.
Write a one-page CTO decision record
- Tenant definition and customer-facing isolation promise, including support access and regional constraints.
- Chosen model for application, data, jobs, cache, files, and analytics; document any intentional mixed boundary.
- Threat and failure cases, enforcement owner, negative tests, and restore rehearsal result.
- Representative demand, per-tenant limit, cost assumption, and the evidence that will trigger a model change.
- Named owner for provision, migration, incident response, and the next review date.
If that record cannot be completed, the architecture choice is not ready to scale. Edilec’s SaaS product development service can help turn the decision into a testable tenant model, rollout plan, and operating controls. The useful first conversation is about a real workload and constraint, not a promise that one tenancy pattern always wins.
Frequently asked questions
Does a database per tenant guarantee isolation?
No. It separates a storage resource, but a mis-scoped API, job, export, support tool, or shared cache can still expose another tenant. Test those paths and the operator workflow as well as the database boundary.
When is a pooled model reasonable?
When contractual and regulatory requirements allow shared resources, the team can enforce tenant-aware policy consistently, and representative load plus recovery tests meet the product promise. A pool still needs per-tenant observability and limits.
What should trigger a move to a bridge or silo?
A documented residency or contractual boundary, repeated noisy-neighbor harm, a restoration objective the pool cannot meet, or a materially different workload can justify a move. Decide from evidence and a rehearsed migration path rather than tenant size alone.
Sources and editorial note
This guide was prepared by Edilec Research and checked against the linked primary guidance from AWS SaaS Lens, Microsoft Azure Architecture Center, and OWASP. The hypothetical example is illustrative; no customer result or measurement is claimed.
