SaaSMethodBudgetGDPR
Multi-tenant SaaS architecture, explained for founders
10 min read
A multi-tenant SaaS application serves all its customers from one version of the software, on infrastructure that is partly or fully shared, and each customer only ever sees its own data. Sharing is what makes SaaS economics work: you do not run a hundred servers for a hundred customers. The trade-off is that isolation between customers no longer comes from separate machines. It comes from how the software is designed.
Most of what you will find on this topic is cloud documentation written for engineers. This article is for the founder or executive who has to decide: which model to pick, what it costs, what it protects, and what to say when your first large prospect asks for its own database.
The vocabulary in one minute
- Tenant: one customer of your SaaS. In B2B, a company, with several users, its own data and its own settings.
- User: a person who logs in, attached to a tenant.
- Deployment: a set of infrastructure (servers, database, storage) running the software. It can serve one tenant or many.
- Isolation: the guarantee that one tenant can neither see nor disrupt another tenant's data or performance.
Microsoft's Azure Architecture Center sets out the starting point: in B2B, a tenant usually maps to a customer organisation, and all its employees are users within that tenant. It also stresses that choosing a tenancy model is a commercial decision, not only a technical one.
Three models, plus a hybrid
Cloud providers describe the same models in different words. AWS calls dedicated resources a "silo" and shared resources a "pool".
| Model | What is shared | Isolation enforced by | Cost per tenant | Operations |
|---|---|---|---|---|
| Fully shared (pool) | Application and database | Code (tenant identifier) | Lowest | One thing to update |
| Database per tenant | Application; one database each | The database | Medium | Migrations and backups multiplied |
| Dedicated (silo) | Nothing but the source code | The infrastructure | Highest | Automation is mandatory |
| Hybrid | Shared for most, dedicated for some | Depends on the tenant | Varies | Code must handle both cases |
Fully shared. One application, one database, a tenant column in every table. Microsoft describes it as the cheapest model to run, with three risks to manage: data leaking between tenants, the "noisy neighbor" (one large tenant slowing everyone else down) and updates that hit every customer at once.
Database per tenant. The application stays shared; each tenant gets its own database. Data isolation is stronger, and a tenant hammering its database does not degrade the others. The cost: every schema change has to be rolled out to every database.
Dedicated deployment. Each tenant gets its own stack. Microsoft puts it bluntly: if one tenant needs a certain infrastructure cost, a hundred tenants probably need a hundred times that cost. This is the model for customers with heavy regulatory requirements.
Hybrid. Most tenants share, a few get a dedicated stack. AWS describes exactly this: basic-tier tenants in the pooled environment, premium tenants paying more to run in their own silo. It adds an essential rule: those silos should run the same version and configuration as everyone else, with no one-off customisation.
What the choice means for your business
| Concern | Shared | Dedicated |
|---|---|---|
| Hosting cost | Spread across all customers | Multiplied by the number of customers |
| Risk of data leaks | Depends on code discipline | Limited by the infrastructure |
| Outage | Affects every customer | Affects one customer |
| Updates | Once, for everyone | Rolled out tenant by tenant |
| Sales argument | Low price, instant onboarding | Meets large accounts' requirements |
For an early-stage SaaS, the shared model is nearly always the right starting point: it keeps build and running costs under control while you look for your first customers. Dedicated becomes relevant when a customer is willing to pay for it.
How isolation is enforced in a shared model
Ask your development team this question, and expect a precise answer.
- A tenant identifier everywhere. Every table holding customer data carries it, without exception.
- One central filter, not one per query. If every developer has to remember to filter, one slip exposes another customer's data. A central rule protects you even from code written in a hurry.
- Protection at the database level. PostgreSQL offers row-level security, which restricts the rows each role can see through policies. Its documentation warns that table owners and superusers bypass it by default, so the application must connect with a role that the policies apply to.
- Everything outside the database. Uploaded files, caches, search indexes, exports, logs, scheduled jobs: each must know which tenant it belongs to.
- Tests that try to cheat. An automated test logs in as tenant A and tries to read tenant B's data. Microsoft recommends testing isolation this way, whatever the model.
These measures come on top of the security essentials for any business application, not instead of them.
Demanding customers
Sooner or later a prospect larger than the others sets conditions. The most common:
- A dedicated database or environment, for compliance or internal policy.
- Data residency, in the EU or a specific country, sometimes with a certification. Our guide on where to host a business application in Europe covers the levels of requirement.
- Single sign-on with the customer's own identity provider.
- A written service level and commitments on subprocessors.
A SaaS designed for the hybrid model can say yes without a rewrite: it knows which deployment each tenant lives on and can create a new one automatically. That yes has a cost, which belongs in your price list as a higher plan or a custom quote. Our guide on how to price a B2B SaaS product covers it.
Multi-tenancy and data protection
In a B2B SaaS, you process your customers' data on their behalf. Under the EU's General Data Protection Regulation, that usually makes you their processor, and Article 28 requires you to delete or return personal data at the end of the service, at the customer's choice. In a shared model, that means being able to extract and erase one tenant's data, wherever it lives, without touching anyone else's. Easy if the tenant identifier is everywhere; a project if it is not.
The agreement that covers this, including the data processing agreement, is the subject of the SaaS agreement clauses your customers will ask for.
Start simple, keep the doors open
The most useful advice fits in three points:
- Put the tenant identifier everywhere from version one, even with a single customer. Adding it later means revisiting every table, query and background job.
- Start shared, with a central filter and isolation tests.
- Keep a table that maps each tenant to its deployment. Microsoft notes that a codebase designed for both shared and dedicated deployments lets you move a tenant into its own environment later.
This is also the classic situation of an internal tool becoming a product: our article on turning an internal tool into a SaaS shows that adding multi-tenancy is often the largest part of the job.
Questions to ask your development team
- Which model do you recommend, and why for my case?
- Where is the tenant identifier checked: in one central place, or in each query?
- How do you test that one tenant cannot read another's data?
- How do we delete all of one tenant's data?
- What would it take to give one customer a dedicated environment, and how long would it take?
- How do you roll out an update without interrupting every customer?
Where to start
List your target customers and their likely requirements: size, industry, sensitive data, hosting expectations. If none of them will ask for a dedicated environment soon, start with a well-isolated shared model that is designed to host dedicated deployments one day. If your market is regulated, plan for the hybrid model from the start and build its cost into your price.