Infrastructure

Multi-tenancy

ActivePublished: 1 October 2026Updated: 1 October 2026Published

Key innovation

Enabling a single software instance and shared infrastructure to securely serve many independent tenants with logical isolation of their data and configuration, instead of running a separate instance per customer.

How it works

Each request is associated with a tenant through an identifier (tenant ID / tenant context), typically derived from authentication, a subdomain, or a header. An isolation layer enforces that operations and queries act only within that tenant's data. Data is partitioned using one of three models: separate databases per tenant (strongest isolation, highest cost), a shared database with separate schemas, or a shared database and shared schema with a tenant discriminator column (highest density, lowest cost, strongest reliance on application-layer security). At the deployment level, the silo (resources dedicated to a tenant), pool (shared, scalable resources), and bridge (a hybrid of both) models are used. An overarching control plane manages tenant onboarding, identity, configuration, and lifecycle, while resource governance mechanisms — limits, quotas, and throttling — guard against one tenant degrading the performance of others.

Problem solved

Running a separate, dedicated application instance for every customer is expensive and hard to maintain: the number of environments to update, monitor, and scale grows while resources stay underutilized. Multi-tenancy solves this by letting a single instance serve many tenants on shared infrastructure, while preserving isolation of each tenant's data and configuration.

Components

Tenant context (tenant ID)Identifying and propagating tenant ownership

An identifier that associates every request, record, and operation with a specific tenant. Propagated through the whole stack, from authentication to the data layer.

Tenant isolation layerEnforcing security boundaries between tenants

Mechanisms ensuring that one tenant's data and activity are not accessible to others — from query filtering and access policies to network and runtime separation.

Data partitioningLogical or physical separation of tenant data

The strategy for separating tenant data: separate databases, a shared database with separate schemas, or a shared schema with a tenant discriminator column.

Separate database per tenantStrongest isolation, highest cost per tenant.

Shared database, separate schemasModerate isolation and density.

Shared schema with tenant columnHighest density and lowest cost; requires strong application-layer security.

Official

Tenant control/management planeCentralized tenant management

A shared component responsible for onboarding, identity, configuration, billing, and the lifecycle of tenants — even when their resources are dedicated (silo).

Resource governance (quotas and throttling)Protecting shared resources from imbalance

Limits, quotas, and throttling preventing a single tenant from consuming a disproportionate share of shared resources.

Official

Implementation

Implementation pitfalls

Noisy neighbor problemHigh

A single tenant generating disproportionate load can degrade performance for the other tenants sharing resources.

Fix:Introduce rate limiting, resource quotas, and isolate high-demand tenants (e.g. move them to a silo model).

Cross-tenant data leakageCritical

With a shared schema, missing tenant-ID filtering in even a single query can expose another tenant's data.

Fix:Enforce tenant filtering at the data layer (e.g. row-level security), plus isolation audits and tests.

Loss of tenant contextHigh

If tenant context is not consistently propagated across the whole stack (queues, background jobs, service calls), operations may act on the wrong tenant's data.

Fix:Explicitly carry the tenant identifier through every layer and asynchronous operation.

Evolution

1999

Salesforce popularizes the multi-tenant SaaS model

Inflection point

The commercial success of software delivered as a service on shared, multi-tenant infrastructure established multi-tenancy as the dominant SaaS pattern.

2006

Public cloud mainstreams pool-model economics

The arrival of public cloud (including Amazon EC2) made shared, scalable infrastructure standard, reinforcing the economies of scale of multi-tenancy.