We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Cloud Infrastructure
A single software instance serving multiple customers (tenants) while keeping their data isolated. Can be achieved at the database, schema, or row level.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Multi-Tenancy across a run of lessons, not one page. These 4 alone are about 68 minutes of step-by-step reading, every one with a quiz.
Changing database schemas and data formats in production without breaking running applications.
Both nodes serve traffic simultaneously, maximum utilization, maximum complexity.
Managing application and infrastructure configuration in version-controlled files instead of manual settings.
Defining what your infrastructure should look like and letting systems converge toward it automatically.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Schema Evolutionpay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This page explains the idea. The course covers it step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
See the System Design Masterclass coursecourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Multi-Tenancy in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
