Imagine a SaaS product serving two companies. One customer starts an intensive export, and the other suddenly sees much slower responses. Worse, a filtering bug exposes one company's data to the other. Both incidents involve tenant boundaries, but the failures and remedies are very different.
Multi-tenancy is not one technology. It is a decision about which resources customers share and where isolation is enforced.
What is worth sharing, and what becomes risky?
Shared applications and infrastructure avoid running a separate server for every tenant. The company can ship updates centrally and use capacity more efficiently. Those economies often underpin SaaS pricing.
Shared resources also create dependencies between neighbours. One customer can consume compute, queue capacity or database connections. A missing tenant check can turn an ordinary software defect into cross-customer data exposure.
So examine isolation separately for data access, compute resources, network boundaries, operational recovery and deployment cadence. A separate database does not magically fix bad authorization; a shared process does not necessarily mean no isolation.
One product can support several isolation levels
At one end are shared tables with strong tenant scoping. Other designs use separate schemas or databases. Some customers may need dedicated environments or particular data-residency controls.
Deeper separation generally increases the operational bill: migrations, backups, monitoring and upgrades multiply. Maximum isolation is not the default answer. It has to match the consequences of failure and what the customer contract actually requires.
A large tenant changes the workload for everyone
Security isolation and resource isolation are different problems. Even if data is protected, one customer may saturate a common queue or connection pool. Limits, quotas, separate worker pools or workload isolation may be necessary.
Those limits must reflect product promises. Throttling legitimate usage without matching the customer's contracted service level is a different kind of product failure.
Test the decision with four scenarios
I would ask the team to walk through an accidental cross-tenant query, a large customer's traffic spike, restoring one tenant from backup and rolling out a change to only part of the customer base.
The answers reveal which boundaries matter. Sometimes better authorization and quotas are enough. Sometimes a dedicated database or environment is a justified business requirement.
Good multi-tenancy does not isolate everything. It contains the real risks of sharing without destroying the economics of a common platform.