Serving many customers from one system.
WHAT MULTI-TENANCY MEANS
One running system serving many customer organisations.
WHAT THE APPROACHES ARE
Shared database, with a tenant identifier on every row Separate schema per tenant Separate database per tenant Separate instance per tenant
WHAT SHARED DATABASE PROVIDES
Lowest cost, simplest operation, easiest upgrades.
WHAT IT RISKS
Data crossing between tenants, if any query omits the filter.
WHY THAT IS THE CENTRAL DANGER
One missing condition exposes one customer's data to another, and that is a serious breach.
WHAT PREVENTS IT
Scoping enforced at the data layer, not in each query Automatic application of the tenant filter Tests verifying isolation
WHAT TO NEVER RELY ON
Developers remembering to filter.
WHAT SEPARATE DATABASES PROVIDE
Stronger isolation Per-customer backup and restore Easier compliance arguments
WHAT THEY COST
Operational complexity, and migrations run many times.
WHAT TO CHOOSE INITIALLY
Shared, with rigorous scoping, unless a requirement dictates otherwise.
WHAT REQUIREMENTS DICTATE OTHERWISE
Regulatory demands for separation Very large customers with specific terms
WHAT TO BUILD IN FROM THE START
The tenant concept, everywhere.
WHY
Retrofitting multi-tenancy is among the most painful changes possible.
