About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Choose tenancy separately for application execution, data storage and infrastructure. A separate customer database does not necessarily mean a separate application runtime or physical server. Conversely, a product sold as software as a service can use isolated deployments for individual customers.
The useful question is what customers share, which controls enforce their boundaries and which failures can still affect several customers. Avoid presenting “single-tenant” as a complete security or availability guarantee.
Separate the layers before comparing designs
NIST SP 800-145 defines cloud service models and deployment models. SaaS, PaaS and IaaS describe the capabilities supplied and controls retained. Private, community, public and hybrid describe deployment models. Those categories do not prescribe an ISV's application tenancy design.
Microsoft's multitenant architecture overview describes a range from sharing resources among all tenants to deploying isolated resources for each. Intermediate approaches trade scale, isolation, cost, performance and manageability. Its deployment-stamp examples show that different customers can use shared or dedicated groups of resources within the same product.
Use a table like this to make your own design explicit:
| Layer | Example arrangement | Boundary still to assess |
|---|---|---|
| Application | Separate runtime per customer | Shared identity, deployment and management services |
| Database | Separate database per customer | Shared database service capacity and operator access |
| Data model | Shared tables with tenant identifiers | Every query, cache, export and background job |
| Compute | Separate virtual machines | Shared host, storage, network and management plane |
| Physical infrastructure | Dedicated host | Other shared dependencies and privileged administration |
These are examples, not equivalent isolation levels. State what each protects and what remains shared.
Match the boundary to the customer's requirement
Ask whether the buyer needs independent maintenance timing, a particular location, a performance commitment, customer-specific configuration or a specific security boundary. Translate that request into measurable controls and operating responsibilities.
A customer asking for a dedicated database might primarily want independent data restoration. Another might mean protection from resource contention. Those are different requirements. Separate databases can help with some data-management operations, but they do not automatically guarantee dedicated underlying throughput or independent service availability.
Microsoft's multitenant storage guidance discusses noisy neighbours, tenant-specific configuration, scaling and operational complexity. It is Azure architecture guidance, so validate the capabilities of the actual storage product before adopting an example.
Our recommendation is to record each buyer requirement alongside the control, its evidence and its limit. For example: “Separate tenant database; restore process rehearsed in isolation; database service capacity remains shared.” That is more useful than an unqualified “fully isolated”.
Evaluate the cost of operating many deployments
Dedicated customer deployments need an operating model for provisioning, patching, certificates, configuration drift, monitoring and retirement. Automation can make that manageable, but automation itself requires version control, failure handling and testing.
Shared deployments concentrate those activities, while requiring careful tenant-aware behaviour throughout the application. An omitted filter in a report, an incorrectly scoped background task or a cache key that lacks tenant context can cross the intended data boundary. Treat these as design and test cases rather than assuming a login check protects every later operation.
Do not choose architecture from customer count alone. Compare infrastructure, support effort, release management and the cost of meeting the promised service requirements. A low infrastructure bill can be offset by expensive exceptions, while separate stacks can be viable where pricing supports them.
An illustrative decision
Suppose an ISV has small customers using a standard workflow and a larger customer needing a separate maintenance schedule and data region. This is a planning example, not a customer case study.
One candidate design is a shared deployment for the standard service and a dedicated deployment stamp for the larger customer. The ISV would still need to identify shared identity, billing, support and deployment systems. It would need a supported release policy for both configurations and a tested process for moving a customer between them.
Another candidate is to keep the application shared but isolate the larger customer's database. That might satisfy a data-management requirement, but it would not by itself provide an independent application release schedule. The requirement decides whether that compromise is acceptable.
Write down the reasons for rejecting each unsuitable design. This prevents a later sales exception from silently undoing the original boundary.
Test the boundary you intend to claim
Use synthetic tenants and isolated test environments to assess access and failure handling. Our recommended checks include:
- Attempts to access another tenant's records, attachments, exports and administrative actions.
- Background jobs and integrations using the intended tenant context.
- Cache and search results remaining scoped correctly.
- Resource contention within the limits the service is intended to support.
- Deployment and restoration processes preserving the documented separation.
Define expected results before testing. A test that two tenants can sign in proves little about whether their data or operational boundaries are correctly enforced. No such tests were executed for this article.
Describe the result honestly
In customer material, name the layer and the remaining dependencies. Separate runtime, separate database and dedicated hardware are different promises. Neither deployment arrangement removes the need for controlled administrator access, secure configuration and verified operations.
Software vendor hosting is the relevant service area for discussing these design requirements. This article does not state that NetLeverage supplies a specific tenancy or isolation model.
Sources and limits
- NIST SP 800-145, September 2011; accessed 14 November 2026. Cloud terminology, not a certification of an implementation.
- Microsoft: Multitenant architecture approaches, accessed 14 November 2026.
- Microsoft: Multitenant storage and data, accessed 14 November 2026.
The decision tables, scenario and test suggestions are editorial recommendations. No lab validation, customer audit or product-specific guarantee is claimed.
Learning notes
Tenancy is a layered design decision. A separate resource can still depend on shared services. Match the architecture and its evidence to the customer's actual requirement before making an isolation promise.
This article was originally published on .