How to let many companies safely share one software platform — each fully walled off, each fast, none paying for their neighbor's size — and the separation provable in an audit.
The tenants on the platform were not roughly similar companies. The largest carried around a hundred times the data of the smallest, and every naive multi-tenant design breaks on exactly that spread: shared tables mean the big tenant's queries crowd out the small one's, shared caches stay warm only for whoever is loudest, and a deploy tuned for one profile degrades the other. "No noisy neighbors" was the requirement, stated as a product promise: each tenant should feel like the only customer.
Tenancy is decided in exactly one place: a proxy in front of everything that maps each request to its tenant and routes it to that tenant's resources. Application code never carries tenant conditionals, because the application never sees more than one tenant's world. When tenancy lives in every query, every engineer is one WHERE clause away from a data leak; when it lives in one proxy, there is one place to test, one place to audit, and one place to get it right.
The conventional answer is a tenant_id column in shared tables. It is cheaper to start and it is the wrong shape for tenants 100x apart: isolation becomes a query-discipline promise instead of a physical guarantee, and the big tenant's load becomes everyone's problem. A database per tenant makes the wall physical — hard isolation, per-tenant backups and restores, per-tenant tuning, and cache warmth that belongs to the tenant rather than to whoever queried last.
A tenant_id column is a promise. A database per tenant is a wall.
Isolation extends to change itself. Blue-green deploys bring the new version up beside the old, shift traffic, and leave a rollback path that costs a routing change — so a deploy is something tenants find out about from release notes, not from downtime. On a platform where tenants run their businesses, "deploys nobody notices" is not an ops nicety; it is part of the product.
Physical separation made compliance conversations short. Each tenant's — and their customers' — data provably lives in its own database: third-party data stays secured inside its boundary, cross-tenant access requires a routing bug rather than a query mistake, and "no misuse of your data" became something we could demonstrate in an audit, not just promise in a contract.
Isolation, resources, cache warmth, and deploys are not four problems — they are one problem wearing four coats. Solve them separately and each fix erodes the others; solve tenancy once, at the routing layer, with physical isolation underneath, and the rest follows. Each company walled off, each fast, none paying for their neighbor's size.