Queries trust the caller to filter correctly
Data separation relies on every part of the application remembering to scope a query. One missed spot is a cross-customer leak.
SAAS PLATFORMS · MULTI-TENANT
One system, every customer separated by design
Multi-tenant means every customer runs on the same application and database, separated logically rather than each getting a physical copy. Every query is scoped to the customer making it, enforced at the database layer, not left to a part of the application remembering to filter correctly.
THE RANGE OF PRACTICE
What unscoped separation looks like, and what enforced separation looks like
Described by behaviour, not by a score.
Scoped in most places, not tested systematically
The application generally filters by customer, but there is no deliberate test suite proving it holds under every code path.
Scoping enforced at the database layer, tested deliberately
Separation is not just application logic that could be forgotten, it is enforced structurally and verified on purpose.
WHERE WE SIT
Enforced structurally, tested deliberately
From
A cross-customer data leak is the single most damaging failure mode a multi-tenant system can have, so separation is enforced at the database layer and tested deliberately rather than assumed to hold from application logic alone. Where a customer genuinely needs complete infrastructure separation instead, single-tenant is scoped as the honest answer, not forced into a multi-tenant shape.
STRAIGHT ANSWERS
Questions about multi-tenant architecture
The ones that come up before anyone signs anything.
Every customer runs on the same application and the same database, separated logically inside the system rather than each getting their own physical copy. One codebase, one deployment, many customers using it at once, each seeing only their own data.
Every query is scoped to the customer making it, enforced in the application and the database layer, not left to a client remembering to filter correctly. A bug in that scoping is the single most damaging failure mode a multi-tenant system can have, which is why it is tested deliberately rather than assumed to work.
One set of infrastructure serves every customer, so adding the hundredth customer costs a fraction of what standing up a hundredth isolated instance would. The saving compounds as the customer count grows, which is the whole economic case for building SaaS multi-tenant in the first place.
When a customer, a regulator or a contract requires complete infrastructure separation, not just logical separation inside a shared system. At that point single-tenant is the honest answer, scoped separately rather than forced into a multi-tenant shape it was never designed for.
Send us your website address. We will tell you what is wrong with it.
A technical review covers speed, security, how search engines see your platform, and what your current setup really costs each year. Two days, no charge, no obligation.