Multi-tenant SaaS architecture: the models, the risks and how to choose

Tenant

A SaaS customer treated as the unit of isolation: an organisation with its own users, data and settings. In B2B it is usually a company; in B2C it can be a person, a family or a group, as Microsoft's guide to tenancy models points out with the example of a music service offering family plans.

What does multi-tenant architecture mean in practice?

In practice it is one application that always knows which customer it is working for. Every request carries the tenant's identity, and every read or write is limited to that tenant.

The opposite is single-tenant: a separate deployment for every customer. It is easier to reason about, but each new customer is another copy to update, monitor and pay for. Microsoft's guide puts it bluntly: if one tenant needs a certain infrastructure cost, a hundred tenants probably need a hundred times that.

What are the main multi-tenant models?

There are three, silo, pool and bridge, in the vocabulary of the AWS Well-Architected SaaS Lens. What changes is how much customers share, and with it cost, isolation and operational effort.

AWS makes a point that often gets lost: even in a silo model, identity, onboarding and operations stay shared. That is what separates SaaS from a managed service where every customer runs a different install with a different process.

How do you isolate one tenant's data from another's?

You isolate it at several layers at once: in the application code, in the database and in your tests. No single layer is enough, because any of them can contain a bug.

In the application

Every table holding customer data carries a tenant ID column, and the server derives the request's tenant from the authenticated user, never from a parameter the browser sends. Queries go through one data-access layer that always applies the filter, instead of relying on whoever writes each query to remember it.

In the database

PostgreSQL adds a second safety net through row security policies, better known as row-level security: the database itself returns only the current tenant's rows. Note one detail in the docs: superusers and roles with the BYPASSRLS attribute always bypass these policies, and table owners normally do too unless you enable FORCE ROW LEVEL SECURITY. Running the application under its own non-owner role avoids the trap.

In your tests

Every sensitive operation needs an automated test that tries to read or change another tenant's data and expects to fail. Microsoft's guidance is explicit: whatever model you pick, test that one tenant's data cannot leak to another.

Among the failures OWASP lists under A01 Broken Access Control is the textbook multi-tenant bug: viewing or editing someone else's account by supplying its identifier, known as an insecure direct object reference. That is why isolation never rests on a single line of code.

What is the noisy neighbour problem?

It is what happens when one customer uses so many resources that everyone sharing them slows down. It mostly hits the pool model: a huge export, an integration hammering the API, a heavy report at peak time.

The defences are well known: per-tenant rate limits, queues for long-running jobs, indexes designed for tenant-scoped queries, and the option to move a heavy customer onto dedicated resources, in effect a bridge model for that one account. It can even become part of the offer: Microsoft notes that you can charge a higher rate for a single-tenant deployment, which ties into SaaS pricing models.

Which model should an early-stage SaaS choose?

For nearly every early-stage SaaS the sensible choice is pool, with strict isolation and a door left open to bridge. It is cheaper, runs as a single environment and lets you learn from customers quickly.

Silo makes sense from day one only if customers demand it in their contracts, as in Microsoft's example of software for law firms, or if you have a few very large accounts. Choosing a tenancy model, Microsoft writes, is a commercial decision as much as a technical one. The foundations it sits on, from database to framework, are in the best tech stack for a startup MVP.

What do EU privacy rules and enterprise buyers expect?

They expect you to prove that one customer's data cannot reach another. If you process personal data for EU customers, Article 32 of the GDPR requires security appropriate to the risk, including the ability to restore data and access after an incident, and Article 28 governs the contract with anyone processing data on someone else's behalf.

Larger B2B buyers often send a security questionnaire before they sign, and data isolation is usually on it. A sound multi-tenant design makes three common requests easy: export everything belonging to one customer, delete it at the end of the contract, and say where it is hosted. For the legal side of your case, talk to a privacy professional.

How do you check that tenant isolation holds?

With a checklist you rerun after every significant change. This is ours, written for a pool model on a relational database.

1. Every table with customer data has a tenant ID, indexed.
2. The server determines the tenant from the session, never the client.
3. Queries go through a data-access layer that always applies the filter.
4. The most sensitive tables have a second defence in the database, such as row-level security.
5. Automated tests try to reach another tenant's data, and must fail.
6. Files, job queues, caches and logs are separated by tenant, not only the database.
7. Per-tenant usage limits protect against noisy neighbours.
8. Exporting and deleting a single customer's data has actually been tried.
9. Backups and restores are tested, and you know what restoring one customer means.

If you are still shaping the product, this list slots into the foundations described in how to build a SaaS product.