Services

Resources

Company

Multi-tenancy

Multi-tenancy is a software architecture in which a single deployment of an application serves many customers, called tenants. Tenants share compute, databases or clusters, but each one sees only its own data and settings. Most B2B SaaS (software as a service) products are multi-tenant, because running a separate stack for every customer costs too much to operate.

How it works

Teams choose an isolation level per layer. In a pooled model, all tenants share tables and every row carries a tenant_id that each query must filter on. In a siloed model, each tenant gets its own database, schema, Kubernetes namespace or cloud account. Authorization must check tenant boundaries on every request. For example, a user in tenant A requesting /invoices/42 from tenant B should get a 404, not the invoice.

Why it matters in production

A single missing tenant filter becomes a data leak across customers. Shared resources also create noisy neighbours, where one heavy tenant slows everyone else. Teams need per-tenant rate limits, quotas, metrics and a clear plan for moving a large tenant to dedicated infrastructure.

See also

On the One2N blog

References

  1. Multi-tenancy (Kubernetes documentation)

Comic about multi-tenancy: three customers share one app and one invoices table with a tenant_id column; an endpoint without the tenant filter shows Pat tenant B's invoice, and a scoped query returns 404; tenant C's export slows everyone until Asha adds a per-tenant limit.