Multi-tenant SaaS architecture: keeping customer data apart
In a SaaS product many customers share one system, and no customer's data may reach another. The three main tenancy models, what each costs, and the mistakes that lead to data leaks.
When a product is sold as SaaS, tens or hundreds of customers use the same system. Each customer — a "tenant" — should feel the system is theirs alone: their data, their settings, their users.
How that isolation is built is one of the earliest and longest-lived architectural decisions in a SaaS product.
Three main models
1. Shared database, shared tables
Every customer in one database and one set of tables. Each row has a column saying which customer it belongs to.
- Upside: the simplest and cheapest. A new customer is just a row.
- Cost: isolation depends entirely on the code being careful. One query without the tenant filter is a data leak.
2. Shared database, separate schema
Each customer has its own set of tables in the same database.
- Upside: stronger isolation; per-customer backup and restore become possible.
- Cost: every schema change runs for every customer. It gets harder to manage as numbers grow.
3. A separate database per customer
- Upside: the strongest isolation. Suits large customers and regulated industries.
- Cost: the most expensive to run and maintain.
| Model | Cost | Isolation | Suits |
|---|---|---|---|
| Shared tables | Low | Code-dependent | Many small customers |
| Separate schema | Medium | Good | A moderate number of customers |
| Separate database | High | Very strong | Enterprise and sensitive data |
How to choose
- Who are your customers? A thousand small stores differ from ten banks.
- Is there a legal requirement? Some sectors demand physical separation.
- What is your pricing? If a customer pays a small monthly fee, a dedicated database doesn't pay for itself.
Many products run a hybrid: the shared model for most customers and a dedicated database for enterprise ones. That only works if it was designed in from the beginning.
Security rules you can't skip
Most data leaks in multi-tenant systems come from a simple oversight. These rules prevent it:
- The tenant id comes from the session, not the request. Never trust an id the user sent in a URL or body.
- Apply the tenant filter in one central layer. No developer should have to remember it in every query.
- Make the database a guard too. Features such as row-level security block access even when the code slips.
- Write isolation tests. A test that explicitly checks customer A cannot see customer B's data.
- Don't forget files and caches. Leaks aren't only from the database; uploads, caches and queues need separating as well.
What else needs to be per-tenant
- Settings and branding: each customer has its own tone, colours and rules.
- Usage limits: one heavy customer must not slow the system for everyone.
- Billing and quotas: usage counted per customer.
- Logs and audit: the ability to view one customer's events on their own.
An example from real work
Pasokhinoo is a multi-tenant SaaS: each store has its own knowledge, channels and tone, and its data is isolated from the others. In a product where an AI assistant answers from store knowledge, that isolation matters twice over: one store's answer must never be built from another store's information. The mechanics are in how an AI sales assistant works.
The takeaway
Tenancy is a decision that is very expensive to change later. Pick the model from your customer type and real requirements, make isolation structural, and test it.
It is one of those decisions that should be written down. If you are designing a SaaS product, see architecture and technical planning.