Multi-tenant SaaS architecture: isolation, cost, and blast radius

Multi-tenancy is the core architectural decision of any SaaS: how do you serve many customers from shared infrastructure without their data — or their load — leaking into each other? The answer is a spectrum from cheap-and-shared to expensive-and-isolated, and where you land depends on what your data's sensitivity demands.

The isolation spectrum

• Row-level (shared tables, a tenant_id column) — cheapest and simplest to operate, but isolation is only as good as your query discipline; a single missing filter leaks data. Enforce it in the database with row-level security, never only in application code.
• Schema- or index-per-tenant — each tenant gets its own schema (Postgres) or index (OpenSearch); stronger isolation, more operational overhead, and it stops scaling past a few thousand tenants.
• Database- or namespace-per-tenant — full isolation, easy per-tenant backup and residency, highest cost and ops burden; reserved for the largest or most sensitive tenants.

Most systems mix these: row-level for the long tail of small tenants, dedicated resources for the enterprise few who require it.

When isolation is a hard requirement

Sometimes the choice isn't about cost at all. If some data is confidential and some is public — unpublished patent applications versus granted, public ones — the segregation between them is a legal requirement, not a performance tuning. That kind of boundary belongs enforced at the datastore level (separate indices or databases, row-level security the app can't bypass), because 'we filter it in the query' is one bug away from a breach. The rule from the query-safety post applies system-wide: the boundary that protects one customer's — or one classification's — data lives in infrastructure, not in a prompt or a WHERE clause the app assembles.

Noisy neighbors and cost attribution

Shared infrastructure means one tenant can starve the others — the noisy-neighbor problem. Per-tenant rate limits and quotas cap any single tenant's blast radius, and per-tenant cost attribution (tokens, compute, storage tagged by tenant) tells you who's expensive and lets you price accordingly. Without attribution, a handful of heavy tenants quietly erode the margin on everyone else.

Audit, residency, and compliance

Regulated and enterprise buyers need more than isolation. Audit logging — who accessed what, when — is table stakes for security reviews. And data residency (EU customers' data staying in the EU for GDPR, for instance) can force region-per-tenant deployment, which reshapes the whole architecture. These aren't afterthoughts; for the clients who care, they're on the buying checklist before features are.

Multi-tenancy is a dial between cost and isolation — and for confidential data, someone else has already set the dial for you. Enforce the boundary in infrastructure, because the app layer will eventually get it wrong.