SaaS multi-tenant architecture: silo, bridge and pooled models
Compare silo, bridge and pooled SaaS architecture models, understand their isolation, cost and operations tradeoffs, and choose a model using a practical decision worksheet.
In this guide
What is multi-tenant SaaS architecture?
A multi-tenant SaaS product serves multiple customer organisations (tenants) through a product that may share application code, infrastructure or data storage. A tenant is a customer boundary, not simply an individual user account. The architecture decision is about where tenant resources are separated and how every request stays within the correct boundary. AWS groups common storage approaches as silo, bridge and pool; the names describe patterns, not security certifications.
Silo: dedicate a storage or infrastructure boundary
A silo gives each tenant a separate database, account, deployment or other resource. It can make some isolation, customisation or tenant-specific recovery requirements easier to reason about, but provisioning, upgrades, monitoring and cost can grow with each dedicated environment. A separate database is not automatically secure if shared credentials or application code can still select the wrong database.
Pool: share resources and scope data by tenant
A pooled design places multiple tenants in shared resources, commonly a shared database or schema, and associates each record or operation with a tenant key. It can simplify onboarding and common operations, but application and data-access paths must consistently enforce tenant scope. One omitted filter can expose another customer's record, so pooled storage calls for deliberate guardrails and negative tests.
Bridge: combine shared and dedicated parts
A bridge design shares some layers while separating others, such as a shared application with tenant-specific schemas or a dedicated database for a small set of customers. It can support different customer needs without making every tenant fully siloed, though routing, migrations, support and observability become more complex. AWS notes that SaaS teams can also mix silo and pool at different parts of a product.
| Tenant requirement | Evidence or contract | Silo / bridge / pool fit | Operational owner | Question to validate |
|---|---|---|---|---|
| Isolation or residency need | ||||
| Traffic and data profile | ||||
| Recovery or customisation need |
How should a SaaS team choose a partitioning model?
Start with customer and business requirements
List contractual promises, data-location restrictions, isolation expectations, customisation, retention, recovery and support needs. Confirm which statements are actual obligations and which are preferences. Ask a qualified security or legal adviser to interpret sector-specific requirements; do not infer that a particular model by itself satisfies a law or certification.
Compare the whole operating cost, not only database cost
Estimate provisioning, patching, monitoring, capacity, backup, restore, migration and support work for the expected number and size of tenants. Include the engineering effort to prevent cross-tenant access in a pool and the deployment effort of many isolated environments in a silo. The cheapest initial design can become expensive if tenant growth forces a rushed migration.
Plan for uneven tenant demand
A few very active customers can consume a disproportionate share of database, queue or API capacity. Decide how to measure tenant-level consumption, set fair limits where appropriate and isolate exceptional workloads. Test whether one tenant's spike slows another tenant before promising uniform performance.
How can you introduce multi-tenancy without losing control?
Make tenant context explicit from authentication to storage
Resolve a user's organisation membership from trusted server-side identity and authorisation data. Pass a validated tenant context through the request and data-access layers; do not trust a tenant ID supplied only in a URL, form or client-side state. Apply the same rule to files, search, exports, caches, background jobs and integrations.
Migrate one tenant path at a time
Document the current data location, mapping, owner, backup and rollback point. Test a repeatable migration on representative data, verify counts and ownership after transfer, and make retries safe so a partial failure does not duplicate or misassign records. Keep a way to pause or roll back the migration until reconciliation passes.
Set tenant-aware operational signals
Monitor latency, errors, queue age, storage growth and resource use by tenant or tier where privacy and scale permit. Alert on cross-tenant access denials, unexpected data volume and unusual consumption. Restrict operational dashboards so they do not expose customer data to staff who do not need it.
Multi-tenant architecture questions founders ask
Is a pooled SaaS database always less secure?
No. A pooled database can be designed with strong tenant scoping and tested controls, but shared access paths make consistent enforcement essential. A silo also needs secure identity, credentials, deployment and operations. Assess the complete system and your customer requirements rather than treating one model as a security verdict.
Should an early startup begin with a silo or a pool?
There is no universal best choice. A silo may fit a migration from an existing single-customer system or a verified isolation requirement. A pool may simplify standard onboarding and shared operations if the team can enforce and test tenant context everywhere. Compare the likely customer mix, operating capacity and cost before choosing.
Can one SaaS product use more than one model?
Yes. A product may use pooled resources for most tenants and dedicate selected storage or infrastructure to customers with substantiated needs. That hybrid adds routing, deployment, support and migration complexity, so make the differences visible in tooling and automate them where possible.
Does tenant separation prove regulatory compliance?
No. Architecture is one part of a broader legal, contractual and operational assessment. Requirements depend on the service, data, jurisdiction and promises made to customers. Get qualified review and keep evidence for the controls you actually operate.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; project-team editorial review pending · Sources checked .
- AWS SaaS Storage Strategies: SaaS partitioning modelsAmazon Web Services
- AWS SaaS Lens: Preventing cross-tenant accessAmazon Web Services
- AWS SaaS Lens: Testing multi-tenant SaaS reliabilityAmazon Web Services