The decision
Tenant isolation is a boundary to design and verify, not a field added to a table at the end. Start by defining what a tenant owns, who may cross that boundary and whether individual customers need independent recovery or infrastructure. Microsoft’s architecture guidance describes shared and isolated storage approaches; the choice remains specific to your operating model.
A worked example
Imagine a SaaS used by separate repair companies. A technician at company A must not retrieve company B's job by guessing its identifier. Exercise list pages, search, attachments, exports, background jobs and support access as separate paths. One protected detail page does not establish isolation everywhere.
Define the tenant boundary in ordinary work
List the records that belong to a company and the records deliberately shared across companies. A public product catalogue may be shared while prices, customer contacts and work orders remain private. Define what happens when a person belongs to two companies: switching the active company should change the entire working context, including search, file downloads and exports. Do not rely on a visual company label to provide that boundary. The server must establish the user's membership for the operation being requested. Document any privileged support path separately, including its authorisation, duration and record of use.
Test leakage through indirect paths
Use two synthetic companies with deliberately similar records and users with different permissions. Try identifiers from the other company in detail routes, exported reports, attachments and background operations. Warm a cache under one company, then request similar information under the other. Remove a user's membership while work is waiting and decide whether the queued job should continue under an explicitly authorised service identity or be cancelled. These tests are about the intended authority at execution time, not just whether the initial screen hid a button. Review negative cases when new search, export or integration features are added.
Treat recovery and deletion as isolation requirements
Ask how the team will restore one customer's accidentally deleted records without rewinding every other customer's work. A separate database may make some operational tasks easier, but each restore still needs verification of attachments, identifiers and dependent systems. With shared storage, selective recovery requires a deliberate procedure and safe staging environment. Rehearse the chosen method with synthetic data before promising it to customers. Similarly, define export and deletion boundaries, including derived indexes and backups under the applicable retention process. The design decision is complete only when normal access, privileged access and recovery all follow an understandable tenant boundary that the operating team can demonstrate.
Alternatives worth weighing
- Shared tables can simplify operating a small product but require consistent tenant-aware access. Separate databases give a stronger operational boundary and add migration, connection and backup work. A hybrid can serve different customer needs, provided the support team understands both arrangements.
Where the plan breaks
Do not trust a tenant identifier supplied by the browser without checking membership. Include tenant context in cache keys and file access decisions. Test a user changing organisations and losing access while a queued job is still pending.
Before you commission the work
Can one customer's data be restored or exported independently? Who authorises support access, and is it recorded? Discuss those requirements during SaaS design; a storage diagram alone cannot settle them.