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)

Four-panel comic explaining Multi-tenancy. Multi-tenancy is an architecture where one deployment of software serves many customers, called tenants, while keeping their data and access isolated.