A platform that serves many institutions, such as municipal offices, schools or village councils, cannot build and operate separate software for each. It also cannot let one institution see another’s data. Multi-tenancy is how you square those two facts, and the first design choice is the isolation model.
1. Shared schema, tenant column
All tenants share the same tables, and every row carries a tenant identifier. It is the cheapest to run and the easiest to upgrade. The risk is that a single missed filter exposes another tenant’s data, so enforcement must be systematic: database row-level security or a query layer that cannot omit the tenant condition.
2. Schema per tenant
Each tenant has its own schema inside a shared database. Isolation is stronger, and tenant-specific customisation is easier. The cost is operational: every migration runs once per tenant, and thousands of tenants strain tooling.
3. Database per tenant
The strongest separation: independent backup, restore, residency and even encryption keys per tenant. It is also the most expensive, and it makes cross-tenant reporting harder.
How to choose
- Sensitivity: how bad is a cross-tenant leak, legally and politically?
- Count and size: many tiny tenants favour shared infrastructure.
- Customisation: do tenants need different fields or workflows?
- Residency and audit: must a tenant’s data be separable and exportable?
- Operations: what can the team realistically run and upgrade safely?
Shared services, separate data
The payoff of multi-tenancy is that identity, reporting, audit and notification services are built once. A fix or improvement reaches every institution at the same time, without any of them sharing records.