Multi-tenancy
Multi-tenancy is an architecture in which one deployment of an application serves many customer organisations, called tenants, with each tenant's data, configuration and access kept apart from every other tenant's, even though they all run on the same underlying system.
Submit a project Plan a multi-tenant SaaS productReviewed by Huy Nguyen (David), CEO · Updated 21 Oct 2026 · 4 min read
This term is one of the entries in the OutsourcingVN glossary of words buyers meet while planning a product more than one customer will use.
Why does multi-tenancy matter?
The decision to build multi-tenant or not shapes almost everything else about a SaaS product's architecture, because retrofitting isolation into a system that was designed for one customer is a costly change to make once customers are live. OutsourcingVN is operated by Netbase JSC, and the practical question a buyer should ask early is not whether multi-tenancy sounds advanced, but whether more than one customer organisation will genuinely use the product within its first year; if so, tenancy belongs in the first design decision, not an afterthought bolted on once a second customer signs.
What is an example of multi-tenancy in practice?
A scheduling product for clinics and salons is built so each business that signs up becomes its own tenant: its staff, appointments and client records are visible only within that tenant, even though every tenant's data lives in the same running application. A clinic that also wants its data kept in a separate database, for its own compliance reasons, can be given that while every other tenant continues sharing the pooled database, because the isolation choice can be made per tenant rather than fixed for the whole product.
What are the common misreadings of multi-tenancy?
Multi-tenancy is not the same as a multi-user application: a single-tenant system can easily have many users, such as every employee of one company signing in to one internal tool, but they all belong to the same organisation and see the same shared data; multi-tenancy specifically means separate customer organisations sharing one deployment while being kept apart from each other. It is also not the same as per-customer hosting, where each customer runs its own separate installation with its own onboarding, management and operations; that approach avoids the isolation design problem but loses the efficiency of one shared deployment. Giving one tenant dedicated resources, such as its own database, does not end multi-tenancy: AWS calls this a silo model, and it remains SaaS while every tenant is onboarded, identified and operated through one shared system.
Plan the next step for your project
Common questions
No. Common isolation models include a shared database with a tenant identifier on every row, a separate schema per tenant, or a fully separate database per tenant, and a single product can mix these per module.
No. Tenants commonly see different configuration, plans or feature flags; what multi-tenancy fixes is the separation of their data and access, not a requirement that every tenant's experience be identical.
Which decisions does multi-tenancy affect?
Planning a product around tenants, roles, plan states and releases rather than a feature list alone is the subject of the SaaS product development workflow, which assumes multi-tenancy has already been chosen as the shape of the product. Where the earlier question is whether to build a custom product at all rather than subscribe to an existing one, custom build versus SaaS covers that choice. When you know how many customer organisations your product will serve, describe it and Netbase will respond through Netbase's own outsourcing-services platform; submit a project when you are ready.