17/09/2026
Every SaaS product answers one architectural question before it answers any others: when two customers use the same system, how far apart are their data, their compute and their failure modes? That question is called tenancy, and the answer shapes cost, compliance, release cadence and incident blast radius for the life of the product.
Most teams pick a tenancy model early, when the product has one customer and the decision feels theoretical. It stops being theoretical the first time a regulated buyer asks where their records physically live.
# # What a tenant actually is
A tenant is one customer organisation and everything that belongs to it: users, records, files, configuration, audit history. Tenancy is the set of rules that keeps one tenant's world separate from the next one's.
Separation happens at several layers, and they are independent of each other:
- **Data.** Separate rows, separate schemas, or separate databases.
- **Compute.** Shared application processes, or processes dedicated to one tenant.
- **Storage.** Shared object buckets with key prefixes, or dedicated buckets.
- **Identity.** Shared authentication with a tenant claim, or a dedicated directory.
- **Release.** Everyone upgrades together, or each tenant upgrades on its own schedule.
A system can be pooled at one layer and isolated at another. "Multi-tenant" on its own is not a specification.