Multi-tenant isolation, explained for a non-engineer buyer: what "tenant-scoped" should actually mean

If you're evaluating a multi-tenant SaaS platform — an RMM, a PSA, anything that will hold more than one of your clients' data in the same system — you'll hear the phrase "tenant isolation" or "logically isolated" from every vendor. It sounds precise. It usually isn't, because there are at least two very different ways to build it, and the phrase alone doesn't tell you which one you're getting.

The two versions, in plain terms

The common version is application-level isolation: every screen, every report, every API call in the software is written to only show you your own data, by filtering on a "which client does this belong to" field every single time. This works — as long as every single piece of code that touches data remembers to apply the filter, forever, including new features built next year by engineers who weren't there when the original design was decided.

The stronger version pushes the same guarantee down into the database itself, so that even a piece of application code that forgets the filter still cannot retrieve another client's rows — the database refuses at the storage layer, independent of what the application asked for. This is a meaningfully different guarantee: one depends on every engineer, forever, getting every query right; the other doesn't depend on that at all.

Questions that actually distinguish the two, without needing to read code

• "If a bug in your application code forgot to filter by client, what would stop it from returning another client's data?" A vendor with database-level isolation has a specific, confident answer. A vendor with application-only isolation usually answers with "we test for that thoroughly," which is a process promise, not a guarantee.
• "Is isolation enforced by the database itself, or only by the application code that queries it?" This is the direct version of the same question, and a vendor who understands their own architecture will answer it plainly.
• "Does a unified dashboard or support-access feature require loosening isolation to work?" A well-built cross-client view is a read path that respects the same boundary; if a vendor says their support team needs standing access across all client data to build convenience features, that's the isolation model quietly weakening for the sake of the feature.

"Tenant-scoped" is a claim. "Enforced by the database, independent of application code" is a guarantee. Ask which one you're being sold.

We've written the engineering-level version of this before: Nexus enforces isolation with PostgreSQL row-level security in addition to application-level filtering, specifically so the guarantee doesn't rest entirely on every future query getting it right. You don't need to understand row-level security to evaluate a vendor on this axis — you just need to ask the question above and notice whether the answer is specific or reassuring.