What is Multi-Tenancy?
Also called multitenant architecture, tenant isolation.
Multi-tenancy is an architecture in which one deployment of a system serves many independent customers, called tenants, whose data and activity must remain separated. Isolation can be enforced at the row, schema, database, or infrastructure level, with stronger separation costing more to operate. Every query, cache key, background job, and log line must carry tenant context or isolation fails.
Isolation models form a spectrum. Shared tables with a tenant column are cheapest and easiest to operate but place the entire burden on correct filtering in application code. A schema or database per tenant gives clearer separation and simpler per tenant export or deletion at the cost of migration complexity across many instances. Fully separate deployments give the strongest guarantee and the highest operational overhead.
The dangerous failure is cross tenant leakage, where one tenant sees another's data. It rarely comes from the obvious query. It comes from an unscoped cache key, a background job that iterates without a tenant filter, an export that reuses a query written for an administrative context, a search index missing the tenant field, or a log or error report that includes another tenant's content. Defense in depth, such as row level security in the database, catches what application code misses.
Noisy neighbor effects are the operational counterpart. One tenant issuing an unusually heavy workload can consume shared capacity and degrade everyone else. Mitigations include per tenant rate limits and quotas, fair scheduling in worker pools, separate queues for heavy workloads, and moving the largest tenants to dedicated capacity when shared resources cannot be partitioned finely enough.
Multi-tenancy also shapes observability. Aggregate metrics can look healthy while one tenant experiences a total outage, so dashboards and objectives generally need a per tenant view, at least for the largest accounts. Traces, logs, and usage records should carry a tenant identifier so any investigation can be scoped to the customer who reported the problem.
Key points
- One deployment serves many customers with isolated data.
- Isolation ranges from a tenant column to separate deployments.
- Leaks come from caches, jobs, exports, and logs, not just queries.
- Per tenant limits prevent one workload degrading others.
- Aggregate metrics hide single tenant outages.
In practice
A platform stores every record with a workspace identifier and enforces the filter in the database rather than trusting application code. Cache keys are prefixed with the workspace, so a cached list cannot be served across boundaries. A nightly job that once iterated all records now runs per workspace. Usage dashboards break out the twenty largest workspaces individually, because an outage confined to one would vanish in the aggregate.