Term · Apps & software
Multi-tenancy
Multi-tenancy is a software architecture in which a single application serves many customers — "tenants", usually organisations — while keeping each tenant's data, users and settings separate. It is the foundation of most SaaS products.
[ 01 ]
Explained
Approaches to isolation
- Shared database, tenant identifier: all tenants' data in the same tables, each row marked with its tenant. Efficient; requires strict enforcement in every query.
- Separate schemas: each tenant has its own set of tables in one database.
- Separate databases: each tenant has its own database. Strongest isolation; more operational overhead.
Hybrid approaches — for example, separate databases for large enterprise clients — are common.
What must be tenant-aware
- Data access in every query and API.
- Users, roles and permissions within each tenant. See designing roles and permissions.
- Settings, branding and configuration.
- Plans, limits and billing.
- Backups, exports and deletion per tenant.
- Logs and monitoring that identify the tenant.
Why decide early
Adding multi-tenancy to an application built for one company is a deep change: data model, queries, permissions and infrastructure all need rework. If a product may serve several organisations, design for it from the first version.
Security
The most serious risk is data leakage between tenants — one customer seeing another's data. Isolation must be enforced on the server, tested explicitly and reviewed in security audits.
[ 02 ]
FAQ
Frequently asked questions
Is multi-tenancy only for SaaS?
Mostly, but internal platforms serving several companies in a group, or several branches with separate data, can use the same pattern.
Can tenants customise the product?
Within designed limits — settings, fields, branding. Deep per-tenant customisation undermines the benefits of a shared system.