Multi-tenancy in SaaS: models and when to use each

You are building a SaaS and, sooner or later, the question that decides half your architecture shows up: how do you keep one customer’s data apart from everyone else’s? All your customers live in the same system, but none of them can see or touch another’s information. How you solve that — what we call multi-tenancy — shapes your infrastructure cost, your security, how fast you can grow, and even which customers you will be able to sell to.

We touched on it in our SaaS development guide; here we give it a proper home. In this guide we explain the multi-tenancy models that exist, the real scenarios where we pick each one, and the mistakes that get expensive when isolation is decided too late.

What multi-tenancy really means

Multi-tenancy is serving many customers (tenants) from a single application without spinning up a copy of the system for each one. The opposite — a separate install per customer — is easy to grasp and brutally expensive to maintain: every update is multiplied by the number of customers and the business does not scale.

In practice, almost everything comes down to three data-isolation models, from most separated to most shared:

• Silo: one database (or one instance) per customer. Maximum isolation, the easiest to explain to a demanding customer, and the most expensive to operate and update.
• Bridge: a shared database with one schema per customer. A reasonable middle ground, though managing hundreds of schemas and their migrations carries its own cost.
• Pool: every customer in the same tables, separated by a tenant_id column. Maximum density and the cheapest to scale, but isolation depends entirely on your code — and your database — never picking the wrong tenant.

The choice is not ideological: it depends on your sector, your compliance obligations, the size of your customers and how fast you expect to grow.

Real scenarios we come across

The SaaS that is just starting: pool with tenant_id

For most products getting off the ground, the pool model is the right call: cheap, dense and fast to build. The real work is not the model, it is hardening it. Here we back the isolation with row-level security in the database itself, so that “forgetting the tenant_id” in a query does not expose another customer’s data. Isolation cannot rest on the developer remembering.

The enterprise customer that demands its own isolation

A large customer arrives and their security team sets a condition: their data does not share a database with anyone. If your architecture is pure pool and you had not planned for this, promoting that customer to a silo can turn into a mini-project. That is why we design the tenant boundary so specific customers can be moved to stronger isolation without rewriting the application.

The regulated sector: healthcare, fintech and data residency

In healthcare or fintech, isolation and data residency are not a commercial preference: they are a requirement. Sometimes they force a silo per customer, or even hosting certain tenants in a specific region. These constraints have to be known before you pick the model, not discovered once the contract is signed.

The “noisy neighbour” that drags everyone down

In a shared model, a single customer firing heavy queries or processing huge volumes can degrade performance for everyone else. That is the noisy-neighbour problem. It is handled with per-tenant limits, queues and resource isolation for the big customers, but it has to be designed on purpose: it does not fix itself.

How we approach it

After building several multi-tenant SaaS products, the order we follow saves the most expensive refactors.

tenant_id from day one, even if you start in pool

Even if you begin with the simplest model, the tenant concept lives in the data model from the very first table. Adding isolation once you already have customers in production is one of the most dangerous refactors there is; leaving the right seam at the start costs very little.

Isolation lives in the database, not just in the code

Trusting isolation solely to every query filtering correctly by customer is fragile: one careless endpoint is enough to leak data across tenants. So we reinforce it at the data layer (row-level security, per-tenant policies), so isolation does not depend on nobody ever making a mistake.

Design so customers can be promoted from pool to silo

The architecture we prefer starts in pool and lets a specific customer move to its own schema or its own database when the business calls for it, without rewriting the product. That way you do not pay the cost of a silo for everyone from day one, but you can offer it when a large customer demands it.

Migrations and operations built for many tenants

With many customers, a database migration stops being trivial: you have to apply it safely and repeatably across every tenant, with a way back. Operating a multi-tenant SaaS — migrating, backing up, restoring a single customer — is designed, not improvised.

Mistakes to avoid

• Leaving isolation for “when we need it”. Retrofitting multi-tenancy later, with customers in production, is one of the most expensive and risky refactors there is.
• Trusting isolation to application code alone. A single endpoint that forgets the tenant_id leaks data across customers. Reinforce it in the database.
• Choosing silo by default “for safety”. One database per customer from day one multiplies your cost and your operations without most customers ever asking for it.
• Ignoring the noisy neighbour. Without per-tenant limits, one heavy customer degrades the experience for everyone else.
• Forgetting multi-tenant migrations. What is easy with one database becomes a serious problem across hundreds if you did not design for it.

How to choose a team for your multi-tenant SaaS

The multi-tenancy model is one of those early decisions the business pays for over years. When choosing who to build it with, look for people who ask about your sector and compliance obligations before proposing a model, who explain how they will reinforce isolation in the database and not only in the code, and who leave the door open to isolating the customers that demand it without rewriting the product. A good team does not pick the fashionable model: it picks the one that fits your business and how you grow.

At LMNHUB we build multi-tenant SaaS as what it is: an engineering project on top of your business. We decide the isolation model with your sector in front of us, reinforce it at the data layer, and leave it ready to scale and ready for the senior team for startups that will maintain it.

If you are designing your SaaS or have run into a customer demanding more isolation than you have, tell us about your case and we will get back to you with a concrete plan and a senior team, no hot air and no generic quote.