Multi-Tenancy
A single software instance serving multiple customers (tenants) while keeping their data isolated. Can be achieved at the database, schema, or row level.
What is Multi-Tenancy?
In short
Multi-tenancy is an architecture where one running instance of software serves many customers, called tenants, while keeping each tenant's data and configuration isolated from the others. The isolation can live at the database level, the schema level, or the row level, so tenants share infrastructure without seeing each other's data.
What Multi-Tenancy Actually Means
A tenant is one customer account, which might be a single company, a team, or a workspace. In a multi-tenant system, all tenants run on the same application code and usually the same servers and databases. When you log into Slack, Salesforce, or Notion, you are using software that thousands of other companies are using at the exact same moment on the exact same machines. Your data feels private because the system enforces boundaries, not because each company gets its own copy of the app.
The opposite design is single-tenancy, where every customer gets a dedicated, isolated stack. Single-tenancy is simpler to reason about for isolation but expensive: 10,000 customers means 10,000 deployments to patch, monitor, and pay for. Multi-tenancy trades some isolation complexity for huge savings in cost and operational effort, which is why nearly every modern SaaS product is multi-tenant.
The hard part of multi-tenancy is making sure tenant A can never read or write tenant B's data, even when a bug or a crafted request tries to cross the line. Every query, cache key, file path, and background job has to carry a tenant identifier and respect it.
How Isolation Works Under the Hood
There are three common isolation models, and real systems often mix them. The first is database-per-tenant: each tenant gets its own physical database. Isolation is strong and you can back up or restore one customer alone, but managing 50,000 databases and running a schema migration across all of them is painful and slow.
The second is schema-per-tenant: one database, but each tenant has its own set of tables inside a separate Postgres schema or MySQL database namespace. This is a middle ground. You get logical separation and per-tenant backups are still reasonable, but connection pooling and migrations get harder past a few thousand tenants.
The third and most common at scale is the shared schema, also called row-level multi-tenancy. All tenants share the same tables, and every row carries a tenant_id column. Every single query must filter by tenant_id. This is the cheapest and easiest to scale to millions of tenants, but it puts the entire burden of isolation on application correctness. Postgres Row-Level Security policies and ORMs with mandatory tenant scoping exist precisely because one forgotten WHERE tenant_id = ? is a data leak.
When To Use It And The Trade-Offs
Use multi-tenancy when you are building SaaS with many customers who do not each need radically different infrastructure. It cuts your hosting bill, lets you ship one fix to everyone instantly, and keeps onboarding a new customer as cheap as inserting a row. For a product with thousands of small and medium accounts, shared-schema multi-tenancy is almost always the right call.
The trade-offs are real. A noisy neighbor, one tenant running heavy queries or a traffic spike, can degrade performance for everyone unless you add rate limits, per-tenant query budgets, or connection quotas. A single bad deploy or a leaked query can affect or expose all tenants at once, so the blast radius is larger than single-tenancy.
Compliance and large enterprise deals often force a hybrid. A bank or a healthcare customer may demand their data live in a dedicated database or even a dedicated region. Mature SaaS companies usually run shared-schema for the long tail of customers and offer a dedicated single-tenant tier for the few enterprise accounts willing to pay for it.
A Concrete Example
Take a project management tool like a Jira or Asana clone. Every workspace is a tenant. A tasks table has columns id, tenant_id, title, status, and assignee. When a user in workspace 4821 loads their board, the API attaches tenant_id = 4821 from the authenticated session and every query becomes SELECT * FROM tasks WHERE tenant_id = 4821 AND status = open.
To stop a forgotten filter from leaking data, the team turns on Postgres Row-Level Security. They set a session variable like app.current_tenant after authentication, and a policy on the tasks table only returns rows where tenant_id matches that variable. Now even a query that omits the WHERE clause returns only the current tenant's rows, because the database itself enforces the boundary.
Caching follows the same rule. A Redis key for a cached board is namespaced as tenant:4821:board:open rather than board:open, so two tenants can never collide on a shared key. The same tenant prefix flows into background jobs, search indexes, and file storage paths.
Where it is used in production
Salesforce
One of the earliest large-scale multi-tenant SaaS platforms; a shared metadata-driven schema serves over 150,000 customer orgs on common infrastructure.
Slack
Each workspace is a tenant on shared infrastructure, with data partitioned by workspace so messages never cross between companies.
Amazon RDS and Aurora
Used by SaaS builders to implement database-per-tenant or schema-per-tenant isolation, with per-tenant snapshots and restores.
PostgreSQL Row-Level Security
Lets shared-schema apps enforce tenant isolation at the database layer so a missing tenant filter in app code cannot leak rows.
Frequently asked questions
- What is a tenant in multi-tenancy?
- A tenant is a single customer account that shares the application and infrastructure with other customers but has its own isolated data and configuration. A tenant is usually a company, a team, or a workspace, not an individual user. One tenant can have many users inside it.
- What is the difference between multi-tenant and single-tenant?
- Multi-tenant means many customers share one running instance and often one database, with isolation enforced in software. Single-tenant means each customer gets a dedicated, isolated stack. Multi-tenant is far cheaper and easier to update; single-tenant gives stronger isolation and is often required for high-compliance or large enterprise customers.
- What are the three main multi-tenancy isolation models?
- Database-per-tenant gives each tenant its own database for the strongest isolation. Schema-per-tenant puts each tenant in a separate schema within one database for a middle ground. Shared-schema, or row-level, keeps all tenants in the same tables with a tenant_id column and is the cheapest and most scalable, but relies on every query filtering correctly.
- What is the noisy neighbor problem?
- It is when one tenant consumes a large share of shared resources, like CPU, database connections, or I/O, and slows down the system for every other tenant. Multi-tenant systems fight it with per-tenant rate limits, query budgets, connection quotas, and sometimes moving heavy tenants onto dedicated capacity.
- How do you prevent data leaks between tenants?
- Attach a tenant identifier to every request after authentication and require every query, cache key, file path, and background job to carry it. Enforce it at the database layer too, for example with Postgres Row-Level Security, so a single missing WHERE tenant_id filter in application code cannot expose another tenant's rows.
Learn Multi-Tenancy hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Multi-Tenancy as part of a larger topic.
See also
Related glossary terms you might want to look up next.
Database Partitioning
Dividing a large table into smaller, more manageable pieces while keeping them in the same database. Sharding is partitioning across servers.
RBAC
Role-Based Access Control: assigns permissions to roles (admin, editor, viewer), then assigns roles to users. Simpler to manage than per-user permissions.
VPC
Virtual Private Cloud: a logically isolated section of the cloud where you launch resources in a virtual network you define. Controls IP ranges, subnets, route tables, and gateways.
Virtual Machine
A software emulation of a physical computer running its own OS on shared hardware. Heavier than containers but provides stronger isolation.
Hypervisor
Software that creates and manages virtual machines by abstracting physical hardware. Type 1 (bare-metal) runs directly on hardware; Type 2 runs on an OS.
Cloud Region
A geographic area containing one or more data centers (availability zones). Choosing the right region reduces latency and satisfies data residency requirements.