Isolation is a spectrum
Every multi-tenant SaaS product answers one question early, often without noticing: how far apart should one customer's data sit from another's? The answer sets the cost of each new customer, the effort of every schema change, the size of the worst possible data leak, and whether the product can pass the security review of its first large enterprise customer.
There are three common answers, usually described as pooled, bridged and siloed. In the pooled model every tenant shares one database schema, and every row carries a tenant key. In the bridged model each tenant has its own schema inside a shared database. In the siloed model each tenant has its own database. They are points on a spectrum, trading cost and operational simplicity against isolation, and most mature products end up using more than one of them.
Pooled: one schema, a tenant key everywhere
The pooled model is the cheapest to run and the fastest to grow. A new tenant is a row in a table. A schema change is applied once. Queries across tenants, for analytics or support, are ordinary queries.
Its risk is that isolation depends on every query being correct. One missing filter on a tenant key exposes one customer's data to another. The defence is to take isolation out of individual queries: set the tenant context once per request, and enforce it in the database with row-level security, so a query that forgets the filter returns nothing rather than everything. PostgreSQL's row-level security does this well. Back it with automated tests that attempt cross-tenant reads on every endpoint, because the failure this model fears is silent. These belong in continuous integration: for each endpoint, authenticate as one tenant and request another tenant's records by ID, and fail the build if any request succeeds.
The pooled model's other weakness is the noisy neighbour. One tenant running an expensive report slows every other tenant sharing the database, so pooled systems need per-tenant rate limits and query budgets from the start.
Bridged: a schema per tenant
Giving each tenant its own schema in a shared database makes isolation structural rather than a matter of query discipline, and it makes per-tenant backup, restore and deletion considerably easier. It also moves cost into operations. Every migration now runs once per tenant, and a migration that fails halfway leaves tenants on different versions of the schema. Connection pools, monitoring and tooling all have to understand that there are many schemas.
This model suits tens or low hundreds of tenants with meaningful data volumes. At thousands of tenants the migration and catalogue overhead usually outweighs the isolation it buys.
Siloed: a database per tenant
A database per tenant gives the strongest isolation available short of separate infrastructure: separate storage, separate credentials, separate backups, and the ability to place a tenant's data in the region or jurisdiction its contract requires. It contains noisy neighbours completely and makes a data-deletion request a matter of dropping a database.
It is also the most expensive per tenant, the slowest to onboard, and the hardest to change, since every schema migration becomes a fleet operation across many databases. Connection limits need watching too: an application that opens a pool to every tenant's database can exhaust its connections long before any single database is busy. It suits a small number of large customers who pay for it, and it needs automation from the first tenant — provisioning, migration and monitoring run by scripts, never by hand.
The decision matrix
Decision matrix
Criterion | Pooled (shared schema) | Bridged (schema per tenant) | Siloed (database per tenant) |
|---|---|---|---|
Tenant count it suits | Thousands and up | Tens to low hundreds | Tens, usually large customers |
Isolation strength | Logical; relies on enforced tenant context | Structural within one database | Strongest; separate storage and credentials |
Regulatory and residency fit | Weakest; one database in one region | Moderate | Strongest; each tenant placed where required |
Cost per tenant | Lowest | Moderate | Highest |
Onboarding | Instant: insert a row | Seconds: create a schema | Minutes: provision a database |
Schema migrations | Once | Once per tenant | Once per tenant, across servers |
Noisy neighbours | Most exposed | Exposed | Contained |
Per-tenant backup and restore | Hard | Possible | Straightforward |
Cross-tenant analytics | Simple | Needs aggregation | Needs a separate pipeline |
Tiered isolation
The model most mature platforms arrive at is tiered: pooled by default for the long tail of customers, with siloed isolation offered as a tier to the customers whose contracts, security reviews or regulators require it. The trigger is usually commercial. An enterprise deal surfaces requirements the pooled platform cannot meet — dedicated storage, data residency, customer-managed encryption keys — and the platform either has a path to meet them or loses the deal.
That path is far cheaper to build in advance than under a sales deadline. It needs a routing layer that resolves each tenant to the database holding its data, a tenant key on every row even in siloed databases so that data can move between tiers, and migration tooling that treats every tenant's database as a target.
Signals that the model needs to change
The right isolation model moves with the customer mix, and the signals usually appear before a deal forces the issue. Security questionnaires start asking where each customer's data is stored and who can reach it. One or two tenants grow large enough that their queries dominate the shared database. A prospect's procurement team asks for a data-processing agreement naming a specific region. Support needs to restore one customer's data to a point in time, and the only option is restoring everyone's.
Each of these says that some tenants have outgrown the pooled model. None of them says that every tenant has, which is why the tiered approach — moving only the tenants the signal is about — is usually the proportionate response.
Isolation beyond the database
The database is where isolation is usually discussed and rarely where it ends. Caches keyed without a tenant prefix leak data between tenants. Search indexes, message queues, object storage and background jobs each need the tenant context carried through them. Encryption keys can be scoped per tenant, which limits the damage of a compromised key and lets a tenant's data be made unreadable on request. An isolation model is only as strong as the least isolated component that touches tenant data.
Choosing
Start pooled unless the first customers already demand otherwise, enforce tenant context in the database rather than in application code, and design the routing layer so that moving a tenant to its own database is an operation rather than a project. Revisit the choice when the customer mix changes, not when a deal is already waiting.
This is the core of our Platform & SaaS work, and the isolation controls themselves are reviewed as part of Security Engineering — because the leak that isolation prevents is a security failure before it is anything else.