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
Building multi-tenant authorization system for B2B SaaS in Go using Permify
Multi-tenant SFTP: how we built a zero-ops setup on AWS Transfer Family
How temporal versioning prevents configuration drift in stream processing
References
