Episode 27 · Module 6 · Authorization & Access Control

Multi-Tenant Data Isolation

19 May 2026 · 8:47 · Security for Legal SaaS

8:47 8:47

Your legal SaaS platform stores data for 50 law firms. Firm A's privileged litigation strategy. Firm B's M&A deal terms. Firm C's client communications about a pending regulatory investigation. If Firm A ever sees Firm B's documents, you don't have a bug — you have a lawsuit, a breach notification obligation, and likely the end of your company. Multi-tenant data isolation is the architectural foundation that prevents this. In Episode 25, we covered ethical walls — information barriers within a single firm. Multi-tenancy is the inter-firm equivalent: every firm's data must be completely invisible to every other firm, with no possibility of cross-contamination.

Today’s Lesson

Security for Legal SaaS — Episode 27: Multi-Tenant Data Isolation

The Stakes

Multi-tenant data isolation is the architectural foundation that prevents this. In Episode 25, we covered ethical walls — information barriers within a single firm. Multi-tenancy is the inter-firm equivalent: every firm's data must be completely invisible to every other firm, with no possibility of cross-contamination.

Three Isolation Models

The industry has converged on three primary approaches to multi-tenant data isolation, each with different tradeoffs between security, cost, and operational complexity:¹

1. Shared Database with Row-Level Security (Pool Model)

All tenants share the same database tables. Every row contains a `tenant_id` column, and access is controlled at the row level.

Aspect	Detail
How it works	Every table has a `tenant_id` column. Every query includes a `WHERE tenant_id = :current_tenant` filter. PostgreSQL Row-Level Security (RLS) can enforce this at the database engine level — even if application code forgets the filter
Strengths	Lowest infrastructure cost, simplest operations, easiest to scale horizontally
Weaknesses	A single query bug can expose cross-tenant data. Noisy neighbour problems (one firm's heavy usage affects others)
Best for	Early-stage SaaS with many small tenants and cost sensitivity

PostgreSQL RLS — which we introduced in Episode 8 — is the critical safety net here. RLS policies run at the database engine level, below the application code:²

sql

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

With this policy active, even a query that omits the `WHERE tenant_id = ...` clause will only return rows belonging to the current tenant. The database enforces isolation regardless of application bugs — a defence-in-depth pattern from Episode 4.³

2. Schema-Per-Tenant (Bridge Model)

Each tenant gets their own database schema within a shared database instance. Tables, indexes, and views are duplicated per schema.

Aspect	Detail
How it works	Tenant A's data lives in schema `tenant_a`, Tenant B's in schema `tenant_b`. The application sets the search path to the correct schema at connection time
Strengths	Stronger logical isolation than shared tables. Schema-level backup and restore. Easier to customise per-tenant (additional fields, indexes)
Weaknesses	Schema management overhead grows with tenants. Database migrations must apply to every schema. Connection pool management becomes complex
Best for	Mid-tier SaaS with moderate tenant count (tens to low hundreds) and customisation needs

PostgreSQL's Citus 12.0 introduced schema-based sharding specifically for this model — enabling horizontal scaling across nodes while preserving schema-per-tenant isolation.⁴

3. Database-Per-Tenant (Silo Model)

Each tenant gets their own dedicated database instance — completely separate infrastructure.

Aspect	Detail
How it works	Tenant A connects to `db-tenant-a.rds.amazonaws.com`, Tenant B to `db-tenant-b.rds.amazonaws.com`
Strengths	Strongest isolation — no shared resources at all. Independent backup, restore, and migration. Per-tenant performance guarantees. Simplest compliance story
Weaknesses	Highest cost. Operational complexity scales linearly with tenant count. Cross-tenant analytics requires a separate data pipeline
Best for	Enterprise clients with strict compliance requirements, large data volumes, or contractual isolation mandates

For legal SaaS: Many enterprise law firm clients will contractually require database-per-tenant isolation. Their security teams (and their insurers) want certainty that a vulnerability in the shared application code cannot expose their data to another firm. When a client's RFP says "dedicated database instance," they mean the silo model.⁵

Defence in Depth for Multi-Tenancy

No single isolation mechanism is sufficient. Defence in depth means layering multiple independent controls:⁶

Layer	Control	What It Catches
Application code	Every query explicitly scoped by `tenant_id`	First line of defence — prevents most cross-tenant data access
ORM/query builder	Automatic tenant scoping middleware that injects `tenant_id` into every query	Catches queries where developers forgot the tenant filter
Database (RLS)	Row-level security policies enforce tenant isolation regardless of query content	Catches bugs in both application code and ORM middleware
Network	Tenant-specific database instances or schemas on separate network segments	Prevents lateral access if one database connection is compromised
Testing	Automated cross-tenant access tests in CI	Catches isolation failures before they reach production

The testing layer is often overlooked. Your CI pipeline should include tests that explicitly attempt cross-tenant data access and verify it fails:

python

# CI test: ensure Tenant A cannot see Tenant B's data
def test_cross_tenant_isolation():
    # Set context to Tenant A
    set_tenant_context(tenant_a_id)
    
    # Create a document as Tenant A
    doc = create_document(content="Tenant A privileged communication")
    
    # Switch context to Tenant B
    set_tenant_context(tenant_b_id)
    
    # Verify Tenant B cannot access Tenant A's document
    assert get_document(doc.id) raises NotFoundError
    assert search_documents("privileged communication") returns []

Tenant Context Propagation

The most common source of multi-tenancy bugs is tenant context propagation — ensuring that every component in the request chain knows which tenant the current request belongs to.⁷

The tenant context must flow through:

Authentication — the JWT token or session contains the user's `tenant_id`
API middleware — extracts `tenant_id` from the token and sets it in the request context
Service layer — passes `tenant_id` to every database query and external service call
Database connection — sets `app.current_tenant` for RLS enforcement
Background jobs — async tasks (email notifications, report generation) must carry the `tenant_id` from the originating request
Logging — every log entry includes `tenant_id` for debugging and audit

The background job trap: A scheduled report generation job runs outside a user request context. If it doesn't explicitly set the tenant context, it may default to no tenant filter — and the report includes data from all tenants. This is a real and documented failure mode. Every background job must explicitly set and verify its tenant context before accessing data.⁷

The Snowflake Incident: A Cautionary Tale

The 2024 Snowflake breach affected over 165 organisations, including AT&T, Ticketmaster, and Santander.⁸ Critically, Snowflake's core infrastructure was never compromised. The attackers used stolen credentials — harvested from infostealer malware dating back to 2020 — to log into individual Snowflake accounts that lacked MFA.

The lesson for multi-tenant SaaS is twofold:

Tenant-level security policy enforcement matters. If your platform allows tenants to opt out of MFA, some will — and those are the accounts that get breached. Enforce baseline security requirements across all tenants.
Credential hygiene is a multi-tenant concern. Even with perfect data isolation, a compromised tenant account gives the attacker access to that tenant's data. Combine isolation with strong authentication (Episode 21) and SSO (Episode 22).⁹

Ethical Walls vs. Multi-Tenancy: The Complete Picture

With Episode 25 fresh in memory, here's the complete access control picture for legal SaaS:

Concept	Scope	Mechanism	Failure Impact
Multi-tenant isolation	Between firms	Database isolation (RLS, schema, silo)	Firm A sees Firm B's data — catastrophic
Ethical walls	Within a firm	Application-layer deny rules, search filtering	Conflicted lawyer sees restricted matter — ethics violation
Matter scoping	Within a firm	User-to-matter assignment checks	Unassigned user accesses matter — privilege breach
RBAC	Within a firm	Role-to-permission mapping	User exceeds their access level — unauthorised action

Each layer is independent. A bug in ethical wall enforcement should never compromise multi-tenant isolation. A misconfigured role should never expose data across tenants. Independence between layers is the essence of defence in depth.

What's Next

Episode 28 covers Encryption at Rest vs. in Transit — how to protect data when it's stored on disk, when it's moving between services, and the envelope encryption pattern that makes key management practical.

Sources & Further Reading

Sources & references

AWS, Multi-Tenant Data Isolation with PostgreSQL Row Level Security — RLS patterns for SaaS.
DZone, Multi-Tenant Data Isolation and Row Level Security — implementation patterns.
Redis, Data Isolation in Multi-Tenant SaaS: Architecture & Security Guide — comprehensive isolation model comparison.
Citus Data, Citus 12: Schema-Based Sharding for SaaS — horizontal scaling for schema-per-tenant.
Hunchbite, Multi-Tenant SaaS Architecture: Row-Level Security vs. Schema-Per-Tenant — architectural comparison.
Aloa, How to Build a Multi-Tenant SaaS Database — comprehensive implementation guide.
Dev.to, Multi-Tenant SaaS Data Isolation: Row-Level Security, Tenant Scoping, and Plan Enforcement with Prisma — tenant context propagation patterns.
Cloud Security Alliance, Unpacking the 2024 Snowflake Data Breach — breach analysis.
Push Security, Snowflake: Looking Back on 2024's Landmark Security Event — lessons learned.
OneUptime, How to Design a Multi-Tenant Data Isolation Strategy on Azure SQL Database — Azure-specific guidance.
Wikipedia, Snowflake Data Breach — timeline and impact.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 27 — multi-tenant data isolation. Alice, this feels like one of the highest-stakes topics in the whole series. If your SaaS stores data for 50 law firms, and Firm A sees Firm B's documents...

Alice: Then you don't have a bug. You have a lawsuit, a breach notification obligation, a regulatory investigation, and probably the end of your company. Multi-tenant data isolation is the architectural foundation that prevents this. Every firm's data must be completely invisible to every other firm. No exceptions. No edge cases. No "it only happens under unusual load conditions."

Dan: Mm. And this is different from the ethical walls we covered in Episode 25?

Alice: Right. Ethical walls are intra-tenant — within a single firm. Partner A can't see Partner B's conflicting matter. Multi-tenancy is inter-tenant — between different firms entirely. And it's a different technical problem. With ethical walls, both users are in the same firm, with the same general access rights, and you're carving out specific exceptions. With multi-tenancy, the two firms should have no awareness that the other exists. Their data should be as separate as if they were on different planets.

Dan: Right. So what are the options architecturally?

Alice: Three main models. First, the shared database with row-level security — the pool model. All firms' data lives in the same database tables. Every row has a tenant_id column that identifies which firm it belongs to. Every query must include a filter for the current tenant's ID. PostgreSQL row-level security — which we covered in Episode 8 — can enforce this at the database engine level. Even if your application code forgets the tenant filter on a query, the database itself will only return rows belonging to the current tenant.

Dan: Mm. That sounds like a safety net for developer mistakes.

Alice: It is. And it's essential, because developer mistakes are exactly how cross-tenant data leaks happen. Someone writes a new report query, forgets the WHERE tenant_id clause, and suddenly the report pulls data from all tenants. Row-level security catches that. The policy runs at the database engine level, below your application code. It's defence in depth — the concept from Episode 4.

Dan: Yeah. What's the second model?

Alice: Schema-per-tenant — the bridge model. Each firm gets its own database schema within a shared database instance. Firm A's tables are in schema "firm_a," Firm B's in schema "firm_b." The data is logically separated. It's stronger isolation than shared tables because there's no possibility of a missing WHERE clause exposing other tenants — the tables literally exist in different namespaces. But it adds operational overhead. Every database migration has to apply to every schema. Connection pool management gets complex. And costs scale with tenant count.

Dan: Mm-hmm. And the third?

Alice: Database-per-tenant — the silo model. Each firm gets its own dedicated database instance. Completely separate infrastructure. Firm A connects to one database server, Firm B to another. This is the strongest isolation you can get — there are no shared resources at all. Independent backups, independent performance, independent everything.

Dan: Hmm. But that must be expensive.

Alice: It is. The silo model costs the most and has the highest operational complexity. But here's the thing — many enterprise law firm clients will contractually require it. When a large firm's security team evaluates your platform, and their RFP says "dedicated database instance," they mean it. Their insurers want certainty that a bug in your application code cannot expose their data to another firm. For these clients, the cost of the silo model is built into the contract price.

Dan: Right. So which model should you choose?

Alice: It depends on your stage and your clients. Early-stage SaaS with many small firms — the pool model with row-level security is cost-effective and secure enough if you implement RLS correctly. Mid-tier with moderate customisation needs — schema-per-tenant. Enterprise clients with strict compliance requirements — database-per-tenant. Many platforms start with the pool model and offer the silo model as a premium tier for enterprise clients.

Dan: Mm. You mentioned defence in depth. What does that look like for multi-tenancy specifically?

Alice: <sigh> It means not relying on any single layer. Your application code scopes every query by tenant_id — that's the first layer. Your ORM or query builder has middleware that automatically injects the tenant filter — that's the second layer, catching queries where developers forgot. PostgreSQL RLS is the third layer, catching anything the first two missed. And then — this is the one most teams skip — automated cross-tenant access tests in your CI pipeline. Tests that explicitly try to access Tenant B's data while authenticated as Tenant A, and verify it fails. If you don't test it, you don't know it works.

Dan: Yeah. What about background jobs? Like scheduled reports or email notifications?

Alice: That's the most common source of multi-tenancy bugs. A background job runs outside a user request context. There's no JWT token, no session — just a job processor picking tasks off a queue. If the job doesn't explicitly set the tenant context before accessing data, it may default to no tenant filter. And then the report includes data from all tenants. Every background job must carry the tenant_id from the originating request and set it explicitly before any data access.

Dan: Mm. The Snowflake breach from 2024 — is that relevant here?

Alice: Very relevant, but not in the way most people think. Snowflake's core infrastructure was never compromised. The attackers used stolen credentials — from infostealer malware dating back years — to log into individual Snowflake accounts. Over 165 organisations were affected. AT&T, Ticketmaster, Santander. The critical detail: the compromised accounts didn't have MFA enabled. A valid username and password was all it took.

Dan: Right. So even with perfect data isolation, a compromised account is still a compromised account.

Alice: Exactly. Multi-tenant isolation protects Firm A from Firm B. But it doesn't protect Firm A from an attacker who has Firm A's credentials. That's why isolation has to work together with strong authentication — MFA from Episode 21, SSO from Episode 22. And it's why your platform should enforce baseline security requirements across all tenants. If you let a tenant opt out of MFA, that's the tenant that gets breached.

Dan: Mm. Let me see if I can put the full picture together. Multi-tenant isolation keeps firms separate. Ethical walls keep matters separate within a firm. Matter scoping ensures users only access their assigned matters. And RBAC controls what actions they can take. Four layers, each independent.

Alice: That's exactly right. And independence is the key word. A bug in ethical wall enforcement should never compromise multi-tenant isolation. A misconfigured role should never expose data across tenants. Each layer must stand on its own. That's defence in depth — not just multiple checks, but multiple independent checks.

Dan: Next episode — Encryption at Rest vs. in Transit. How you protect data whether it's sitting on a disk or moving between services.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.