What Is Multi-Tenancy? A Plain-English Guide for SaaS Teams

TL;DR - Multi-tenancy is when a single running application serves many customers (tenants) at once, sharing the same code and often the same database, while keeping each customer’s data private from the others.

• A tenant is one customer of your SaaS: a company, an account, a workspace. Multi-tenant means many of them run on the same system.
• The opposite is single-tenant: a separate copy of the app and database per customer. Simpler to isolate, far more expensive to run.
• You share infrastructure, never data. Every tenant-scoped row carries a tenant_id, and that id has to follow the data into every query, cache key, and file path.
• There are three models (silo, pool, bridge) and a decision behind each. Most mature SaaS ends up pooling the many and siloing a few.

This is the map. Each section links to the deep dive.

The one-sentence definition

Multi-tenancy is an architecture where one instance of your software serves multiple customers, and each customer (a tenant) sees only their own data even though they share the same application and, usually, the same database.

A tenant is not a user. A tenant is a whole customer: a company on your billing plan, an organization, a workspace. One tenant might have five hundred users inside it. Multi-tenancy is about keeping those tenants apart, not the users within a tenant.

The analogy that makes it click

Single-tenant is a detached house per family. Everyone gets their own building, their own plumbing, their own everything. Total privacy, and you pay to build and maintain a whole house for every family.

Multi-tenant is an apartment building. Everyone shares the structure, the foundation, the elevator, the utilities. Each family has a locked unit and cannot walk into anyone else’s. It is dramatically cheaper per family, and the entire job of the architecture is making sure the locks actually work.

That trade (shared cost versus per-customer isolation) is the whole decision, and it has its own post: single-tenant vs multi-tenant.

What you share, and what you must never share

In a multi-tenant system you deliberately share the expensive things: one codebase, one deploy pipeline, one set of servers, usually one database. That sharing is where the economics come from. Adding a customer costs almost nothing.

What you never share is one tenant’s data with another. That separation is enforced entirely in your system, which means it has to be enforced on purpose and in every place data lives:

• Every row carries a tenant_id.
• Every query filters by it, ideally with the database enforcing the filter rather than trusting each query.
• Every cache key is prefixed with the tenant, or one tenant’s cached result gets served to another.
• Every file path is scoped to the tenant and checked on access.

Miss it in one place and you have a leak. The full stack of controls is its own post: tenant data isolation.

The three models: silo, pool, bridge

How much you share is a spectrum, and the industry (following AWS) names three points on it:

• Silo: each tenant gets dedicated resources, often their own database. Strongest isolation, smallest blast radius, cost grows in a straight line with customers.
• Pool: all tenants share infrastructure and tables, separated by a tenant_id. Cheapest economics, isolation enforced in software.
• Bridge: pool most tenants, silo the few who need it (the regulated ones, the whales). Where most mature SaaS actually lands.

Picking one is one of the few architecture choices you cannot cheaply reverse. The full framework, with how each maps to a real database, is in multi-tenant architecture for vertical SaaS.

How tenants actually stay apart

In a pooled model, isolation is not a single switch. It is a set of layers:

1. tenant_id on every row as the foundation.
2. Database-enforced filtering so a forgotten WHERE clause cannot leak data. In Postgres this is Row-Level Security, and it has its own deep dive: Postgres Row-Level Security for multi-tenancy.
3. Per-tenant limits so one noisy tenant cannot starve the shared pool.
4. Per-tenant encryption for your most sensitive customers.
5. A silo for the few whose risk profile a shared environment cannot meet.

You do not need every layer for every tenant. You need enough that the blast radius of a realistic mistake is acceptable. That framing lives in tenant data isolation.

Multi-tenancy is not the same as scaling

A common mix-up: multi-tenancy is about separating customers, not about handling load. You can have a single huge tenant that needs sharding, and a thousand tiny tenants that fit on one small database. Tenancy answers “how do I keep customers apart,” scaling answers “how do I handle growth.” They are different axes and you decide them separately.

How you handle the growth axis (indexes, read replicas, partitioning, sharding, in that order) is a separate ladder: the database scaling ladder.

So which do you need?

For most early vertical SaaS the honest default is pool with a tenant_id and database-enforced isolation, then silo the handful of tenants that compliance or scale forces you to. That path ends at the bridge model on purpose, rather than by a panicked migration later. Which specific tenants force a silo is a customer-and-compliance question, and it is the heart of the single-tenant vs multi-tenant decision.

Summary and where to go next

Multi-tenancy is one application serving many customers on shared infrastructure, with each customer’s data kept private by a tenant_id and the isolation layers around it. The economics come from sharing; the engineering is in the separation.

The deep dives:

• Multi-tenant architecture for vertical SaaS - the three models and how to pick.
• Single-tenant vs multi-tenant - the binary decision and what forces each way.
• Postgres Row-Level Security for multi-tenancy - the database mechanism that enforces isolation.
• Tenant data isolation - the full defense-in-depth stack.

---

Building multi-tenant and want the model chosen before it is expensive to change? I do this as part of Scale Readiness. Book a free 30-minute call and we will map your tenancy model to what your customers and your margins actually need.