Multi-Tenancy: Three Isolation Models and the Tenant That Stalls Them All

Every SaaS hits the multi-tenancy question on day one and then re-litigates it for the next five years. There are three positions on the spectrum, and each one is correct for a different stage and a different risk tolerance.

Shared schema. One database, one set of tables, a tenant_id column on every row. Cheap to operate, fast to onboard a new tenant, easy to do cross-tenant analytics. The risk is that one missed WHERE tenant_id = ? clause leaks one customer's data to another. Row-level security pushes that filter down into the database itself so the app cannot forget. RLS is the minimum safety net here, not a nice-to-have.

Schema per tenant. One database, separate schemas. The connection still pools across tenants, but tables are physically distinct. Backups, migrations, and access control get more granular. Migration runs go from a single ALTER TABLE to a loop over a thousand schemas, which is its own kind of fun at the 3 a.m. on-call hour.

Database per tenant. Strongest isolation, easiest to reason about for compliance and noisy-neighbor concerns. Highest operational cost. You now run a fleet, not a database. Pooling, failover, and observability all multiply.

The failure mode that pushes teams off the shared-schema model is rarely a security breach. It is performance. A single bad tenant query takes an EXCLUSIVE lock on a shared table, or saturates the IO budget, and every other tenant on that database stalls. Row-level security does not protect you from this. RLS is a correctness boundary, not a performance boundary.

The production failure I watched up close: a B2B analytics product with three thousand tenants on shared Postgres. One enterprise customer ran a tenant-scoped DELETE on their own rows during an import retry. The query was correct, the predicate hit only their data, and RLS was enforced perfectly. The problem was that the index they were deleting through did not include tenant_id as a leading column, so the planner picked a sequential scan and held a SHARE lock on the whole table for forty minutes. Every other tenant's writes queued behind it. Dashboards everywhere went red simultaneously, and the support inbox could not tell the difference between an outage and a single bad import.

The fix list is mundane and load-bearing. tenant_id as the leading index column on every shared table. Per-tenant query budgets enforced at the connection or proxy layer. Track p99 latency by tenant, not aggregate. Move the loudest 1 percent of tenants to dedicated databases before they decide for you.

Multi-tenancy is a blast-radius decision dressed up as a cost decision. Treat it like one.