Tenant isolation explained: what it really means for your data

Every SaaS company will tell you they have “tenant isolation.” Almost none of them will tell you what shape it actually takes. The difference matters — the way a vendor isolates your data determines what a SQL bug, a misconfigured query, or a rogue support engineer can and cannot do. There are three common patterns, each with real trade-offs. Here’s a walkthrough you can use to ask the right questions of any vendor.

The three patterns

AWS popularized the silo / bridge / pool taxonomy, and it’s still the cleanest way to think about this.

Silo: one database per tenant

Every customer gets their own database, often on their own infrastructure. A query you write for tenant A literally cannot return data from tenant B because tenant B’s rows don’t exist on this database server.

• Pros: the strongest possible isolation. A SQL bug stays inside one tenant. Compliance auditors love it.
• Cons: expensive, slow to provision new customers, hard to ship schema changes (you migrate N databases instead of one), and operationally painful at scale.
• Where you see it: healthcare SaaS, government tooling, deeply regulated industries.

Bridge: one schema per tenant in a shared database

Tenants share a database server, but each one gets its own schema (a logical namespace inside Postgres or SQL Server). A query has to explicitly target tenant A’s schema, so cross-tenant queries require deliberate action rather than just a missing WHERE clause.

• Pros: good isolation, cheaper than silo, easier to back up individual tenants.
• Cons: schema migrations still touch N namespaces; connection pooling gets complicated; the schema list can grow into the tens of thousands.
• Where you see it: mid-market SaaS with stricter compliance needs.

Pool: shared schema with a tenant ID on every row

All tenants share the same tables. Every row has a tenant_id column. The application layer (and often a row-level security policy at the database) ensures every query filters by the current tenant.

• Pros: cheapest to operate, instant tenant provisioning, simple schema migrations, easy to scale.
• Cons: isolation depends entirely on the correctness of the application layer. A missing WHERE tenant_id = ? clause is a cross-tenant data leak.
• Where you see it: most large-scale B2B SaaS, including Salesforce, Notion, Linear, and the majority of modern CRMs.

Where Vanta CRM sits, and why

We use the pool model with two reinforcements: row-level security (RLS) policies enforced at the Postgres layer, and a tenant-scoping middleware in the application layer that injects the current workspace into every query. Both have to fail for a cross-tenant leak to happen.

RLS at the database means even if a bug in application code forgets to filter, Postgres itself refuses to return rows from a different workspace. The application middleware means even if someone disabled RLS in a future migration, every query that comes through the ORM is still scoped. Belt, suspenders, and a third belt for the suspenders.

What this actually prevents, in plain English

Imagine an engineer ships a new endpoint that lists deals. They forget the workspaceId filter. In a naive pool model, that endpoint would return every deal from every customer — a catastrophic leak. With RLS enforced at the database, the same endpoint returns zero rows, because Postgres refuses to read outside the current session’s tenant context. The bug is embarrassing, but the blast radius is one customer (the developer’s test workspace) instead of all of them.

What to ask any vendor

1. Which pattern do you use — silo, bridge, or pool? A vendor who can’t answer this hasn’t thought about it.
2. Where is tenant scoping enforced — application layer only, or also at the database? Both is the right answer.
3. Do you have row-level security policies in production? If yes, ask for an example. If they can’t produce one, they don’t.
4. What is your blast radius if a tenant-scoping bug ships? The honest answer involves explicit limits, not “our code is well-tested.”

Multi-tenancy is one of those topics where the right answer isn’t always the most expensive one — it’s the one with the right defense in depth for the kind of data you hold. Read our security page for the full rundown, or our CRM security checklist for the wider set of questions to ask before signing.