Multi-Tenant Architecture for Vertical SaaS: Pick the Model on Purpose

TL;DR - How you separate customers is one of the few decisions that is expensive to undo, so make it deliberately. There are three models, and the industry (and AWS) names them the same way:

• Silo: each tenant gets dedicated resources (a database or stack of their own). Strongest isolation, smallest blast radius, highest cost per tenant, cost grows linearly with customers.
• Pool: all tenants share infrastructure and tables, separated by a tenant_id column. Cheapest unit economics, one migration, one backup. Isolation is enforced in software, so it has to be enforced well.
• Bridge: a mix. Most of the system is pooled, while specific tenants (the regulated ones, the whales) get siloed. This is where most mature SaaS actually lands.

For most early vertical SaaS the honest default is pool with a tenant_id and database-enforced isolation, then silo the few tenants that compliance or scale demands. That path ends at bridge on purpose, instead of by panic.

Why this one is worth slowing down for

Most architecture decisions are reversible if you are willing to do the work. This one barely is. Going from pool to silo later means migrating each tenant’s data out of shared tables into its own home, one customer at a time, without downtime. Going the other way, merging siloed tenants back into a shared schema, is worse. So the tenancy model is not a detail you discover later. It is a decision you make on day one, ideally for reasons you can defend.

The good news: the three options are simple to understand, and the right default for a young vertical SaaS is usually clear once you frame it around your actual customers.

The three models

These are the names AWS uses in its Well-Architected SaaS Lens, and the rest of the industry has settled on them too.

Silo. Every tenant runs on dedicated resources: their own database, sometimes their own whole stack. You still manage them through one shared control plane (one codebase, one deploy pipeline, one onboarding flow), but their data never shares a table with anyone else’s. Isolation is as strong as it gets and the blast radius of a bug or breach is a single tenant. The cost is that your infrastructure bill grows in a straight line with your customer count, and every schema change has to run across N databases.

Pool. All tenants share the same infrastructure and the same tables. A tenant_id column on every row is what keeps them apart. This is classic multi-tenancy and it has the best economics by far: one database to run, one migration to apply, one backup to manage, and adding a customer costs almost nothing. The catch is that isolation now lives in your software. If a query forgets its tenant_id filter, one tenant sees another’s data. That risk is manageable (the next section and the database-enforced approach below handle it), but it is real and it is on you.

Bridge. A deliberate mix. Acknowledges that a real SaaS is rarely all one thing. The common shape: your free and small-business tiers run pooled to keep unit costs low, while enterprise customers with compliance requirements or heavy workloads get a dedicated schema or a dedicated database. AWS frames bridge as mixing silo and pool per service based on each one’s regulatory profile, noisy-neighbor sensitivity, and cost. In practice most successful SaaS ends up here.

How the models map to an actual database

“Silo, pool, bridge” is the strategy. Here is what it looks like in Postgres or MySQL, which is the part you actually build.

Database-per-tenant is the cleanest silo. Schema-per-tenant on a shared instance is the classic bridge at the data tier: better isolation than a shared table, without paying for a separate database per customer. Shared-table-plus-tenant_id is the pool, and the safe way to run it is to let the database enforce the tenant_id filter for you with Row-Level Security rather than trusting every query to remember it.

How to choose

Run your situation through these drivers. Each one pushes you toward silo or pool; the bridge is what you get when different parts of your business give different answers.

• Compliance and data residency. A customer bound by HIPAA, GDPR data residency, or a contract demanding physical separation pushes that tenant to silo. Logical isolation in a shared table may not satisfy the auditor.
• Blast radius tolerance. If a single bug exposing cross-tenant data would end the company, weigh silo more heavily for sensitive data.
• Noisy neighbor. One tenant with a punishing workload can starve a shared database. If you have a whale, silo it so it cannot degrade everyone else.
• Cost per tenant. Pool wins decisively. If your model is high-volume, lower-price customers, linear silo cost will wreck your margins.
• Onboarding speed and ops capacity. Pool onboards a tenant in a row insert. Silo provisions infrastructure. A small team ships and operates pool far more easily.

The honest default

For most vertical SaaS starting out, the right answer is pool, with a tenant_id on every table and Row-Level Security enforcing it in the database. It gives you the best economics while you are finding product-market fit, one codebase and one migration to operate, and (with RLS) isolation that does not depend on every developer remembering a WHERE clause.

Then, when a customer arrives with a compliance requirement you cannot meet in a shared table, or a whale shows up whose load would hurt everyone else, you silo that specific tenant. You have now built a bridge, deliberately, one tenant at a time, instead of paying silo costs for everyone from day one out of vague caution. Defaulting to silo “to be safe” is the most common way young SaaS companies destroy their own unit economics.

The traps

Siloing by default. “Dedicated databases are more secure” is true and usually irrelevant for a 20-customer SMB product. You linearize your cost and your ops burden for isolation most of your customers never needed. Pool first, silo by exception.

Pooling without database-enforced isolation. A tenant_id column that is only filtered in application code is one forgotten WHERE away from a breach. If you pool, enforce the boundary in the database, not in everyone’s memory.

Treating the choice as permanent and global. It is neither. It is per-tenant and it evolves. The bridge exists precisely so you do not have to pick one model for the whole business forever.

Forgetting the index. In a pooled database, every index has to lead with tenant_id or your queries scan across all tenants. Cheap to get right early, painful to retrofit.

Summary

The tenancy model is a decision you cannot cheaply reverse, so make it on purpose. Silo gives the strongest isolation at linear cost; pool gives the best economics with isolation you must enforce in the database; bridge mixes them and is where most mature SaaS lands. For an early vertical SaaS, start pooled with a tenant_id and Row-Level Security, then silo the specific tenants that compliance or scale forces. That gets you to a bridge deliberately, with your margins intact.

Tenancy is how you separate customers. Handling growth in load and data is a separate ladder: see the database scaling ladder for when a pooled database starts to strain, and database optimization for the fixes that come before you ever reach for sharding.

Picking the model for a product you are about to build or refactor? I do this as part of Scale Readiness. Book a free 30-minute call and we will map your tenants to the model your margins and your compliance profile actually need.