Multi-Tenancy Models

By the Syncfusion DevTutorials team · Last updated October 20, 2026

Many customers on one system: compare pool (shared tables + tenant key), bridge (schema per tenant) and silo (database or cell per tenant) on cost, isolation, migrations and restore time.

Many Customers, One System

Consumer systems such as feeds, chat and video are mostly about scale: millions of people using one app. A B2B SaaS product adds a different set of problems. It sells to companies, and each company is a tenant: its own users, its own data, its own settings, its own contract.

Fifty companies can share the same servers, but none of them may ever see another's data. Some pay a little and want it cheap. One pays a lot and wants its own database in its contract. One wants its data to stay in Europe. One wants to run your product in its own data centre.

This section teaches those problems one at a time. The HLD Case Studies section then uses them in real product designs.

The main idea: choose how tenants share storage. Pool puts every tenant in the same tables. Bridge gives each tenant its own schema. Silo gives each tenant its own database. Most real products mix all three.

Before You Start

This section builds on HLD Foundations. Check yourself with five quick questions. If you miss two or more, review the Foundations lesson named in the answer first. You can still read on.

TL;DR

• A tenant is one customer company. B2B SaaS runs many tenants on shared infrastructure to keep costs low.
• Pool: all tenants in the same tables, separated by a tenant_id column. Cheapest, one migration per release, but the weakest isolation, and restoring one tenant is slow.
• Bridge: one schema per tenant on a shared database server. Better isolation and faster single-tenant restore, but one migration per tenant.
• Silo: one database (or a whole stack, a cell) per tenant. Strongest isolation, simple restore, the highest cost.
• Real systems mix models: pool the many small tenants, bridge the mid-size ones, silo the few whales who need it.

A Real-World Example

A help-desk startup begins with ten customers in one Postgres database. Every table has a tenant_id column. Life is simple.

Three years later it has 4,000 customers. A bank signs a large contract with a clause: "our data must be in a separate database". A small customer accidentally deletes a week of tickets and asks for a restore. The team discovers that restoring one tenant means restoring the whole 3 TB database to a spare server, finding that tenant's rows and copying them back. It takes a day.

Neither problem is about scale. Both are about how tenants share storage.

What You Will Learn

1. What a tenant is, and the three ways tenants can share storage.
2. How each model affects cost, isolation, migrations and restore time.
3. How to mix models for a real customer base.
4. How to move a tenant from one model to another.

The Three Models

The pool model only works if every query, cache key, job and index carries the tenant. That is the subject of the next lesson.

Here is what "logical isolation" means. The table is shared; the filter is the only wall. Step through it:

Cost

Shared infrastructure is the reason SaaS is cheap. A pool cluster holds hundreds of small tenants for one price. A silo charges a minimum price per tenant, even for a tenant with five users.

The lab uses this teaching cost model:

A silo for every small tenant costs about 18 times as much as pooling them. That is why "isolate everyone" is not the safe default it sounds like.

Migrations

Every release changes the schema a little: a new column, a new index. In the pool, you run that change once per cluster. In bridge and silo, you run it once per tenant, and some will fail halfway.

Restoring One Tenant

Backups protect against disasters. But the most common restore request in B2B SaaS is small: one customer deleted something by mistake and wants yesterday's data back.

The bigger the pool, the slower every pooled tenant's restore. The bigger the tenant, the more it needs a snapshot of its own.

Try It: Place 50 Tenants

Northwind's brief: cost at most $5,000 a month, Contoso and Fabrikam EU in databases of their own (it is in their contracts), and any single tenant restorable in 45 minutes or less.

Start with "Everyone in the pool", read which checks fail, and fix them one at a time. Then try "Everyone in a silo" and see why it fails differently.

Mixing Models

The answer is almost always a mix:

• Pool the many small tenants. They are cheap to serve and rarely need special treatment.
• Bridge the mid-size tenants, so each can be restored, exported or moved on its own.
• Silo the few whales: contractual isolation, their own restore, and their load cannot hurt anyone else (Lesson 3).

A tenant's model is not forever. A tenant that grows from 20 seats to 5,000 should move from the pool to its own silo. Plan for that move from day one: if every row already carries tenant_id, a move is "copy every row where tenant_id = X, switch the routing, delete the old rows".

Common mistakes

Practice

What to Remember

• A tenant is one customer company sharing your infrastructure.
• Pool is cheapest and simplest to migrate, but isolation depends on every query, and single-tenant restore is slow.
• Bridge gives each tenant a schema: better isolation and restore, one migration per tenant.
• Silo gives each tenant a database or cell: the strongest isolation at the highest cost.
• Mix models by size and contract, and keep a tenant catalog so tenants can move.

Further Reading

• AWS: SaaS Tenant Isolation Strategies (whitepaper): the silo, bridge and pool vocabulary used in this lesson.
• Microsoft: Multitenant SaaS database tenancy patterns: single-tenant, multi-tenant and sharded databases compared, with a tenant catalog.
• Citus: Multi-tenant applications: sharding a pooled Postgres database by tenant_id.

Next: Tenant Context and Isolation. A pooled system is only as safe as its weakest hop: you trace one request and find where the tenant goes missing.