Every SaaS product eventually has to answer the same question: when customer A and customer B both use the same application, how much of the underlying infrastructure do they actually share? Get this wrong and you either burn money running near-empty dedicated databases for every small customer, or you build a shared system fragile enough that one noisy tenant degrades everyone else’s experience. AWS’s own SaaS architecture guidance frames this as a spectrum of tenant isolation models — commonly called silo, pool, and bridge — and the choice shapes a SaaS company’s costs, operational complexity, and compliance posture for years.
At a Glance
| Model | What It Means | Best For |
|---|---|---|
| Silo (database-per-tenant) | Each tenant gets its own dedicated database (or full stack) | Regulated industries, large enterprise tenants, strict per-tenant compliance or customization needs |
| Pool (shared schema) | All tenants share one database/schema, separated by a tenant ID column on every row | High tenant counts, cost-sensitive SaaS, consumer-scale multi-tenancy |
| Bridge (hybrid) | A mix — some tenants or resources pooled, others siloed | SaaS products with mixed tenant tiers (e.g. free/standard pooled, enterprise siloed) |
| Primary guidance source | AWS Well-Architected SaaS Lens and the AWS “SaaS Tenant Isolation Strategies” and “SaaS Storage Strategies” whitepapers | — |
Short Verdict
There is no universally “correct” multi-tenancy model — AWS’s own whitepaper on tenant isolation is explicit that the right strategy depends on your domain, compliance requirements, and the specific AWS (or non-AWS) services involved. The pooled, shared-schema model is the cheapest to run at scale and the fastest to onboard new tenants into, but it demands rigorous application-level isolation logic and accepts some risk of one tenant’s load affecting another’s. The silo, database-per-tenant model gives the strongest isolation and the simplest compliance story, at the cost of running — and paying for — essentially duplicate infrastructure per tenant. Most mature SaaS companies end up somewhere in between: a bridge model that pools most tenants for efficiency while siloing the handful that need dedicated resources for contractual, regulatory, or performance reasons.
The Silo Model: Database-per-Tenant
In a silo model, each tenant gets dedicated resources — commonly a dedicated database, sometimes a dedicated full application stack — so nothing is physically shared between tenants. This is the most isolated design available short of running entirely separate installations. Its appeal is straightforward: a noisy or misbehaving tenant can’t degrade another tenant’s performance because they aren’t sharing the same database connections, disk I/O, or compute; a compliance auditor asking “show me this one customer’s data boundary” gets the simplest possible answer; and per-tenant cost attribution is trivial because the infrastructure is already split by tenant. The cost of that isolation is operational: provisioning, migrating, patching, and monitoring N databases instead of one scales linearly (or worse) with tenant count, and onboarding a new tenant means standing up new infrastructure rather than inserting a row.
The Pool Model: Shared Schema
In a pool model, tenants share the same underlying resources — the same database, often the same tables — and isolation is enforced logically rather than physically, typically through a tenant identifier column present on every row and enforced by application code, row-level security policies, or both. AWS’s whitepaper on tenant isolation strategies describes the trade-off plainly when discussing pooled resources generally: “the concepts and tradeoffs of pool isolation tend to be similar for most resources… you’ll find yourself balancing the available isolation mechanisms with the efficiency of having a resource that is shared by tenants.” That’s the whole trade in one sentence — pooling is efficient precisely because it avoids duplicating infrastructure per tenant, and the price of that efficiency is that isolation has to be actively engineered and verified rather than coming for free from physical separation.
The same AWS guidance notes that when a pooled approach proves genuinely difficult for a particular resource, teams are pushed toward either a silo model for that resource specifically, or toward “application-enforced isolation” — meaning the isolation guarantee has to be implemented and maintained correctly in your own code, which is a real and ongoing engineering cost rather than a one-time infrastructure decision.
A Minimal Illustration: Enforcing Pool Isolation
This is a simplified sketch of the application-level discipline a pooled model requires: every query must be scoped to a tenant, with no code path that can accidentally omit the filter.
class TenantScopedRepository:
"""Wraps a shared table and refuses to run any query
without an explicit tenant_id filter."""
def __init__(self, db_connection, table_name):
self.db = db_connection
self.table_name = table_name
def find_by_id(self, tenant_id, record_id):
if not tenant_id:
raise ValueError("tenant_id is required for every pooled query")
query = (
f"SELECT * FROM {self.table_name} "
f"WHERE tenant_id = %s AND id = %s"
)
return self.db.execute(query, (tenant_id, record_id))
def list_all(self, tenant_id):
if not tenant_id:
raise ValueError("tenant_id is required for every pooled query")
query = f"SELECT * FROM {self.table_name} WHERE tenant_id = %s"
return self.db.execute(query, (tenant_id,))
def insert(self, tenant_id, record):
if not tenant_id:
raise ValueError("tenant_id is required for every pooled query")
record = {**record, "tenant_id": tenant_id}
columns = ", ".join(record.keys())
placeholders = ", ".join(["%s"] * len(record))
query = f"INSERT INTO {self.table_name} ({columns}) VALUES ({placeholders})"
return self.db.execute(query, tuple(record.values()))
Notice what this code is actually doing: it’s manually re-implementing, at the application layer, the isolation boundary that a silo model gets for free from using physically separate databases. That’s the real cost of pooling — not just a column on every table, but a discipline that every single query path has to honor, forever, with no second line of defense if a developer forgets the filter. (Row-level security features in databases like PostgreSQL can enforce this boundary at the database layer instead of relying purely on application code, which is why many production pooled systems combine both.)
The Bridge (Hybrid) Model
Few real SaaS products are purely siloed or purely pooled end to end. The bridge model combines both: a common pattern is pooling standard-tier tenants into shared infrastructure for cost efficiency while giving premium, enterprise, or regulated tenants their own dedicated database or stack, often as a paid tier feature in its own right. This lets a SaaS company keep its cost structure sane for its long tail of small customers while still being able to sign the handful of large enterprise or regulated customers whose procurement or compliance teams require dedicated infrastructure as a contractual condition. The cost of the bridge model is architectural: the system now has to actually support two (or more) isolation strategies simultaneously, which means more code paths, more operational runbooks, and more ways for a new engineer to get the isolation boundary wrong.
Comparison
| Factor | Silo | Pool | Bridge |
|---|---|---|---|
| Isolation strength | Strongest — physical separation | Weakest by default — logical only, enforced by code/policy | Varies by tenant tier |
| Cost efficiency at scale | Worst — infrastructure scales with tenant count | Best — infrastructure shared across all tenants | Mixed — pays silo cost only for tenants who need it |
| Onboarding speed | Slowest — new infrastructure per tenant | Fastest — new tenant is just new rows | Depends on which tier a new tenant lands in |
| Compliance/audit story | Simplest to explain and prove | Hardest — requires demonstrating logical controls work correctly | Simple for siloed tenants, harder for pooled ones |
| Operational complexity | High at scale (many databases to patch/monitor) | Low (one system to operate) but high engineering discipline required | Highest — two or more models to build, test, and operate at once |
Trade-offs
- Silo isolation removes an entire category of “did we isolate tenant data correctly” risk, but multiplies infrastructure, patching, and monitoring overhead by tenant count.
- Pool isolation is the cheapest and fastest to operate at scale, but AWS’s own guidance is explicit that it requires ongoing engineering effort to keep isolation correct — there’s no free physical boundary to fall back on.
- A bridge model lets a SaaS company serve very different customer segments economically, but it means maintaining more than one isolation strategy in the same codebase and organization simultaneously.
- None of these models is fixed forever: AWS’s guidance frames isolation choice as something that can and often does vary resource-by-resource within a single SaaS product, not a single company-wide decision made once.
Bottom Line
Multi-tenant architecture isn’t a single switch between “shared” and “dedicated” — it’s a spectrum, and AWS’s own SaaS guidance treats it as a decision made per resource and per tenant tier, not once for the whole product. Start from what actually drives the decision for your product: if compliance or large-enterprise contracts demand dedicated infrastructure for some customers, build a bridge from day one rather than retrofitting it later. If your growth model depends on onboarding large numbers of small or mid-size tenants cheaply, invest early in rigorous, verifiable pool isolation rather than treating a shared tenant_id column as sufficient on its own. The companies that get this wrong usually don’t pick the wrong model outright — they pick a reasonable model and then under-invest in the isolation discipline it actually requires.
FAQ
Is pooled multi-tenancy inherently less secure than database-per-tenant?
Not inherently — but it shifts where the isolation guarantee lives, from the infrastructure layer to the application (and, if used, database row-level security) layer, which means it has to be actively engineered and tested rather than assumed from physical separation.
Can a SaaS company switch from pooled to siloed later for a specific customer?
Yes, and this is exactly what the bridge model is for — many SaaS products start fully pooled and add siloed infrastructure as an option for specific large or regulated customers without rearchitecting the whole system.
Does AWS recommend one model over the others?
No. AWS’s whitepaper guidance frames the choice as dependent on domain, compliance requirements, deployment model, and the specific services involved, explicitly noting there’s no single ideal strategy that fits every resource in every SaaS product.
What’s the single biggest risk in a pooled, shared-schema design?
A code path that queries or writes to the shared table without a tenant filter — whether from a missed check, a background job, an admin tool, or a new engineer unfamiliar with the convention. That single omission is the entire failure mode pooled isolation has to guard against on every query, forever.
Sources
- AWS Whitepaper — SaaS Tenant Isolation Strategies: Isolating Resources in a Multi-Tenant Environment
- AWS Whitepaper — SaaS Storage Strategies: SaaS Partitioning Models
- AWS Well-Architected Framework — SaaS Lens: Tenant Isolation
- Related reading on this site: Google Zanzibar and ReBAC Explained
Discover more from Software Online Review
Subscribe to get the latest posts sent to your email.
