Multi-tenant software: one system, many clients
How one application serves many organisations while keeping their data apart, and the decisions that get it right or wrong.
The short answer
Multi-tenant software is one running system that serves many separate organisations, each seeing only its own data, users, configuration and branding. It is how a product can be sold to a hundred clients with one codebase, one deployment and one set of improvements, instead of a hundred copies. The whole design rests on isolation: every record belongs to a tenant, every query filters by the tenant of the person logged in, and the filter is enforced centrally in code and ideally in the database, never by trusting the interface. A missed tenant filter is not a bug; it is a data breach.
What multi-tenancy involves
| Concern | What it means | Where it goes wrong |
|---|---|---|
| Data isolation | Every record carries a tenant; every read and write is scoped | A query without the filter; an identifier in a URL that reaches another tenant’s record |
| Identity | Users belong to a tenant; some may belong to several | Roles and permissions not scoped per tenant |
| Configuration | Settings, branding, features and limits per tenant | Configuration hard-coded for the first client |
| Operations | Onboarding, support access, usage limits, billing, offboarding and deletion per tenant | No way to export or delete one tenant cleanly |
| Performance | One tenant’s heavy use must not slow the others | Missing limits; queries that scan across tenants |
| Compliance | Per-tenant data residency, retention and export | Everything in one region with no per-tenant control |
Getting isolation right
- Every table carries the tenant as a first-class column, indexed.
- The tenant is derived from the session, never from the request, so a user cannot ask for another tenant’s data.
- The filter is applied in one central layer that every query passes through, not repeated by hand per screen.
- The database enforces it too where supported, with row-level policies, so a bug in the code is still caught.
- Automated tests try to cross the boundary on every build: a user of tenant A requesting tenant B’s records must fail.
- Support access is explicit and logged: staff act inside a tenant only with a recorded reason.
Shared or dedicated data
Shared tables with a tenant column: one database, cheaper, simpler, fine for most products with rigorous isolation code and row-level policies. A database per tenant: stronger isolation, easy per-tenant backup, export and deletion, satisfies clients who require it, at higher operational cost and complexity. A common path is shared by default with the option to move a large or regulated tenant to a dedicated database, which requires the code to have been written with that possibility from the start.
What this means for you
If your software will serve several organisations, design it multi-tenant from the start: tenant on every record, filter derived from the session and enforced centrally, database policies as a second net, boundary tests on every build, and per-tenant configuration, support tooling and deletion. The economics of one system for many clients only work if the isolation is beyond doubt.
Frequently asked questions
When does a business need multi-tenancy?
When the same software will serve several separate organisations: franchisees, clients of an agency, members of a group, customers of a product you sell. If every deployment would otherwise be a copy, multi-tenancy is the design that keeps one codebase, one deploy and one set of improvements for all of them.
How is one tenant prevented from seeing another's data?
By design at every layer: every record carries its tenant, every query filters by the tenant of the logged-in user, the filter is applied in one central place rather than remembered per screen, and automated tests try to cross the boundary. Databases can enforce it too with row-level policies. The interface hiding things is never the mechanism.
Shared database or one per tenant?
Shared tables with a tenant column are cheaper and simpler to operate and fine for most cases with good isolation code. A database per tenant gives stronger isolation, easier per-tenant backup and deletion, and satisfies clients or regulators who require it, at higher operating cost. Many systems start shared and move their largest or most regulated tenants to dedicated databases.
Sources
- OWASP Cheat Sheet Series: Multi-Tenant Application Security Cheat Sheet (accessed 2026-09-12)