title: What "multi-tenant" actually means in legal software slug: what-multi-tenant-actually-means date: "2026-04-01" category: Security author: head-of-platform dek: Vendors throw the word multi-tenant around like it has one meaning. It does not. Here is the difference between application-level isolation, database-level isolation, and the third option that most legal vendors quietly run. tags:
- Security
- Architecture
When a law firm asks "is your platform multi-tenant?" the honest answer is "yes — and you should ask which kind." Three different architectures all call themselves multi-tenant, and the difference matters enormously for the audit trail, the breach blast radius, and the question of whether a misconfigured query can leak another firm's data.
Architecture A — Application-level isolation
The cheapest version. Every firm shares the same database, the same tables, the same rows. Each row has a firm_id column. Every application query is supposed to filter by firm_id. If a developer forgets one filter, that query returns rows from every firm in the system.
The problem is not that developers are careless; the problem is that the surface area is unbounded. Every new feature is a new opportunity to forget the filter. Every legacy ORM helper that pre-dates the multi-tenant rollout is a latent bug. The audit trail, even when it is well-built, only catches what the application thinks happened — not what the database actually returned.
Most legacy legal vendors started here. Many still are.
Architecture B — Database-level isolation (the bare minimum we will accept)
Every firm has its own logical database, schema, or row-level-security boundary that the database engine enforces. The application still sends queries with a tenant context, but if the application forgets to apply the filter, the database refuses the query — it does not silently return data.
This is what we ship in Legasus. Every row in every table is tagged with the firm's organization ID. Postgres row-level-security policies require an authenticated session that resolves to that organization before any read or write succeeds. A misconfigured query does not return another firm's data; it errors out.
The trade-off is operational complexity. Indexes get larger. Background jobs need a session context. Backup and restore is more complicated. But the security property is qualitatively different: a single application bug cannot leak across tenants.
Architecture C — Per-tenant infrastructure
Every firm gets its own database instance, its own object storage bucket, its own queue. Cross-tenant leakage is impossible because there is no shared substrate.
This is the most expensive option, and it is what some larger enterprise vendors offer for their largest customers. The downside is operational: every release ships to N databases instead of one; cross-customer features (firm-wide analytics, cohort dashboards) become much harder.
Which one matters for your firm
If your firm handles privileged communication for celebrity clients, holds escrow for high-value PI cases, or has an opposing party who is also a customer of the same vendor, the question is not academic. Architecture A is unsafe for the first two; the third is impossible to defend against without Architecture C.
For most plaintiff PI firms, Architecture B is the right answer. It is what the Legasus security model is built around, and what the audit trail verifies on every read and write.
The single best question to ask your software vendor is: "If a developer at your company forgets to apply the firm filter on a query, what happens?" The honest answer should involve the database, not the application.
What to ask in your security review
- Where is the tenant boundary enforced — at the application or at the database?
- Show me a single SQL query that would attempt to bypass the boundary, and walk me through how it fails
- What is the audit log emitted when the boundary is violated?
- How do background jobs (export, search indexing, AI inference) carry tenant context?
If the vendor cannot show you the actual database policy or the actual rejection log, treat the answer as "Architecture A with marketing." The cost difference between Architecture A and Architecture B is significant. The cost of a cross-tenant leak is significantly more.
If you want to see the row-level isolation diagram up close, every Legasus security review includes a walk-through of the actual Postgres RLS policies. We have nothing to hide there.