Last updated: August 2026
Multi-Tenancy
Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers — called tenants — each logically isolated from the others while physically sharing the same underlying infrastructure, application code, and often the same database.
How it works
Instead of provisioning a separate deployment of an application for each customer, a multi-tenant system runs one shared instance that serves all customers, distinguishing between them by a tenant identifier attached to every request and every row of data. Tenants typically can't see or access each other's data, and can often customize limited aspects of their experience (branding, business rules, configuration) without being able to modify the underlying application code shared across all tenants.
Isolation models
Multi-tenant systems implement tenant isolation at different levels, trading off resource efficiency against isolation strength. Shared database, shared schema puts every tenant's data in the same tables, distinguished only by a tenant ID column — the most resource-efficient option, but the weakest isolation, since a bug in a query's tenant filter can leak data across tenants. Shared database, separate schema gives each tenant its own schema within a shared database — stronger isolation with moderate resource overhead. Separate databases per tenant gives each tenant a fully isolated database — the strongest isolation, at the highest resource and operational cost.
Code Ninety selects the isolation model based on the specific data sensitivity and regulatory requirements of each client's tenants — a consumer SaaS product with low-sensitivity data can reasonably use shared-schema for cost efficiency, while a healthcare or fintech platform serving multiple enterprise clients often requires separate databases per tenant to meet compliance and contractual data-isolation commitments.
When it applies
Multi-tenancy is the standard architecture for SaaS products serving many customers, since running a fully separate deployment per customer becomes operationally and financially unsustainable past a small number of tenants — patching, scaling, and monitoring N separate deployments costs vastly more than operating one shared, well-isolated system. It's the right default whenever the product is genuinely sold to many independent customers with similar (even if configurable) needs.
When single-tenant is the better choice
Single-tenant deployments — one fully separate instance per customer — remain the right choice when a specific enterprise customer's compliance requirements mandate fully isolated infrastructure with no shared resources at all, when customers need heavy, code-level customization that a shared codebase can't reasonably support, or for early-stage products with very few customers where the operational savings of multi-tenancy haven't yet outweighed the engineering cost of building proper tenant isolation. Retrofitting multi-tenancy onto a system originally built single-tenant is a substantial undertaking — deciding this architecture early, based on realistic customer count projections, avoids an expensive later migration.
Isolation models compared
| Model | Isolation strength | Resource efficiency |
|---|---|---|
| Shared DB, shared schema | Weakest | Highest |
| Shared DB, separate schema | Moderate | Moderate |
| Separate DB per tenant | Strongest | Lowest |
Working with Code Ninety
See Code Ninety's enterprise delivery case studies. See the marketplace platform case study for a multi-tenant commerce build.