Multi-Tenancy

Multi-tenancy is one decision with long consequences: how much do tenants share?

Shared database, shared schema. Every table carries a tenant_id. Cheapest to run, simplest to deploy, best resource utilisation. Isolation depends entirely on every query filtering correctly, so one forgotten WHERE clause is a cross-tenant breach — which is exactly the case for enforcing it with row-level security rather than discipline. Per-tenant restore is painful, because one tenant's data is interleaved with everyone's.

Shared database, schema per tenant. Stronger separation and per-tenant backup becomes tractable. Migrations now run N times, and schema drift between tenants becomes possible, which is its own class of incident.

Database per tenant. Strongest isolation, easiest compliance story, trivial per-tenant restore and per-tenant scaling. Operationally heaviest: migrations across thousands of databases, connection pool pressure, and a far worse cost profile for small tenants.

Most products start shared and move large or regulated tenants to dedicated databases, which is a sensible endpoint — a hybrid where the model is a property of the tenant rather than of the product.

The noisy neighbour problem is inherent to sharing. One tenant running an enormous report degrades everyone. Per-tenant rate limits, query cost caps, and separate pools for heavy tenants are the defences, and they need to exist before the incident.

Design for the tenant dimension early. Retrofitting tenant_id into a schema, every query, every cache key, and every background job is one of the more painful migrations there is — and until it is complete, every one of those places is a potential leak.