Definition
A multi-tenant SaaS architecture serves multiple customers, called tenants, from one shared installation of the software. Each tenant sees and changes only its own data, users and settings. The data is separated by giving each tenant its own database or schema, or by a tenant ID in shared tables. The principle is called multi-tenancy.
Key takeaways
- Multi-tenant software serves many customers from one installation. Each customer sees only its own data, users and settings.
- There are three basic database models: shared tables with a tenant ID, a separate schema or a separate database for each customer.
- Shared tables cost the least. Separate databases draw a clearer line and simplify backup and deletion per customer, but cost more.
- Broken access control ranks first in the OWASP Top 10. In multi-tenant software, it can expose one customer’s data to others.
- Germany’s Standard Data Protection Model requires technical separation. Higher protection needs call for stronger separation.
What is a tenant in SaaS?
A tenant is a customer for whom the software keeps a self-contained space with its own data, users and settings. In SaaS, a tenant is usually a customer company with many employees. All tenants share what they need in the same form, such as the program code or reference data like a list of countries.
In everyday English, a tenant is “a person who pays rent for the use of land or a building” (Cambridge Dictionary). Google explains multi-tenancy with an apartment building: the tenants share the water pipes and electrical lines, but each one has an apartment of their own (Google Cloud, Oct 26, 2026). Recommendation ITU-T Y.3500 from 2014 defines multi-tenancy as an allocation of physical or virtual resources in which tenants “and their computations and data are isolated from and inaccessible to one another” (ITU-T).
In their Standard Data Protection Model (SDM), Germany’s data protection authorities define a tenant as a self-contained context in which a controller stores and processes data (German Data Protection Conference, Oct 6, 2020). Tenants can be the customer companies of a software vendor, but also the hospitals of a hospital group that share IT and still have to process their patient records separately. A single customer may also need several tenants, for example to keep development and production apart (Microsoft, Jun 27, 2025).
This article mainly takes the view of a vendor that serves many customer companies from one application. According to Google, multi-tenancy is part of “most, if not all” software-as-a-service (SaaS) applications (Google Cloud). Our guide What is SaaS? explains how SaaS works as a whole.
When does multi-tenancy matter for your business?
Multi-tenancy matters as soon as a single application has to keep the data of several companies or business units apart. That’s the case if you offer software to other companies as a service, turn an in-house tool into a product or run several companies in one system. If you buy a SaaS product, ask the vendor how it separates tenants.
- You’re building a SaaS product: The tenancy model is one of the first architecture decisions. According to Microsoft, switching to a different model later is sometimes costly (Microsoft, Aug 21, 2025). We make this decision with you in the discovery sprint, before development starts. Our page on SaaS development describes the process.
- You want to turn an in-house tool into a product: Then every record needs to belong to exactly one tenant. For personal data, that’s what the Standard Data Protection Model of Germany’s data protection authorities specifies (German Data Protection Conference, Oct 6, 2020). Retrofitting multi-tenancy means checking every query, every cache and every file store for tenant scoping (OWASP, as of Nov 5, 2026).
- You run several companies or locations in one system: Then each company can be a tenant in shared custom business software, with its own users and roles. Among other measures, the Standard Data Protection Model lists separate systems for assigning permissions.
- You’re buying a SaaS product: Ask which model the vendor uses to separate tenants, who has audited the separation and whether the vendor can restore, return and delete just your company’s data. Our comparison Build vs. buy software weighs buying against building your own.
How does a multi-tenant architecture separate tenant data?
At the database level, there are three basic models. In the first, all tenants share the tables, and every row carries a tenant ID. In the second, each tenant gets its own schema, a separate set of tables in the same database. In the third, each tenant gets its own database. In all three, the tenants share the application.
The numbers in the “Source” column refer to the list of sources at the end of this article.
| Model | How data is separated | Strengths | Weaknesses | Source |
|---|---|---|---|---|
| Shared tables | Every row carries the ID of its tenant. The application and the database filter every access by that ID. | Lowest cost per tenant. New tenants need no new infrastructure. Reporting across all tenants is easy. | A bug in one query can expose another tenant’s data. Restoring a single tenant takes significant effort. Every change affects all tenants at once. | 8, 9, 6 |
| Separate schema per tenant | Each tenant has its own set of tables in the same database. Database roles control who may read which schema. | Per-tenant customization is possible. Shared application data can sit in a common schema. | Schemas aren’t rigidly separated: anyone with the privileges can read other schemas too. Every change to the data model has to roll out to all schemas. | 8, 10, 7 |
| Separate database per tenant | Each tenant has its own database, on a shared or a dedicated database server. | A clear boundary per database. Backup, restore and deletion affect only that tenant. Per-tenant customization is possible. | Higher cost per tenant. Changes have to roll out to every database automatically. Reporting across all tenants takes significant effort. | 8, 9, 6 |
There are options in between. The Standard Data Protection Model lists separate tables per tenant in one database, for example with a tenant prefix in each table name, as an intermediate level of separation (German Data Protection Conference, Oct 6, 2020). Microsoft advises against this approach: a single database can’t support large numbers of tenants that way, and querying, managing and updating data becomes increasingly difficult (Microsoft, Aug 21, 2026).
The strongest isolation is a separate deployment per tenant, with its own application and its own database. Strictly speaking, that’s single-tenant operation, because the tenants don’t share an installation. Costs then grow with every customer. If one tenant requires a certain infrastructure cost, “100 tenants probably require 100 times that cost,” Microsoft notes (Microsoft, Jun 27, 2025).
Mixed forms are common. AWS documentation calls the basic forms pool for shared resources, silo for dedicated resources per tenant and bridge for forms in between (AWS, silo, pool and bridge). For PostgreSQL, AWS counts a separate schema or a separate database on a shared server as bridge, and a separate server per tenant as silo (AWS, decision matrix).
Which tenancy model should you choose?
Shared tables pay off with many tenants that each have little data. Separate schemas suit a moderate number of tenants, and separate databases suit cases where isolation is the top priority. You need a dedicated server per tenant if you have very large, performance-sensitive tenants or must fully control each tenant’s resources. The choice is also a commercial decision.
This is how AWS classifies the models for PostgreSQL (AWS, decision matrix). Microsoft stresses that the choice also depends on your business objectives and on which forms of multi-tenancy your customers will accept (Microsoft, Jun 27, 2025). The following questions help you decide. The numbers in the “Source” column refer to the list of sources at the end of this article.
| Question | Favors shared tables | Favors a separate database or server | Source |
|---|---|---|---|
| How many tenants, and how large? | many tenants with little data each | a few very large tenants | 8 |
| Do customers require their own encryption keys, their own backup rules or a specific storage location? | no | yes | 9 |
| Does a tenant need its own fields or indexes? | rarely; custom fields then go in a separate table | often | 8, 9 |
| How often do you report across all tenants? | often | rarely | 8 |
| Does the load of individual tenants slow down the others? | load is evenly spread | individual tenants create heavy load | 12, 4 |
| Do you need to restore individual tenants often or quickly? | no | yes | 8, 9 |
| How much of your operations can you automate? | little | updates, backups and monitoring run automatically | 4, 9 |
You don’t have to make the same choice for every tenant. Microsoft describes a hybrid model: tenants in a free trial share a database, and tenants who pay for a premium tier get one of their own. All databases carry the tenant ID, so tenants can be moved at any time (Microsoft, Aug 21, 2025). For a first product, we think this is often a good start: shared tables with a tenant ID, protected by a row-level security policy in the database, and later a separate database for large customers.
What are the security risks of multi-tenant software?
The biggest risk is one tenant seeing or changing another tenant’s data. According to AWS, crossing this boundary in any form would be “a significant and potentially unrecoverable event for a SaaS business.” Other risks are shared caches and file storage without tenant scoping, and individual tenants whose load slows down everyone else.
AWS calls tenant isolation “one of the foundational topics that every SaaS provider must address” (AWS, tenant isolation). Access control flaws are common. In the data behind the OWASP Top 10:2025, 100% of the applications tested had some form of broken access control, and the category holds on to first place (OWASP, 2025). One OWASP example involves a platform for online stores: by replacing the store name in the URL of the revenue data, an attacker gains access to the sales data of thousands of stores (OWASP, 2023).
How to limit the risk:
- Resolve the tenant on the server: A tenant ID from the request or a header only selects a tenant. On every access, the server checks whether the signed-in user may act in that tenant and on exactly that record (OWASP, as of Nov 5, 2026; OWASP, 2023).
- Add a second barrier in the database: Row-level security (RLS) policies catch a condition that someone forgot to add to a query. AWS says RLS is required for shared tables in PostgreSQL (AWS, row-level security). Microsoft says it can be complex to design, implement, test and maintain, and that many multi-tenant solutions don’t use it for that reason (Microsoft, Aug 21, 2026). It can also affect performance (Microsoft, Jul 7, 2026).
- Separate outside the database, too: Caches, file storage, queues and logs also need the tenant context (OWASP, as of Nov 5, 2026).
- Limit load: When one tenant’s performance suffers because of another tenant’s activity, Microsoft calls it the noisy neighbor problem (Microsoft, Jun 11, 2025). Per-tenant limits help, for example for requests and background jobs (OWASP, as of Nov 5, 2026).
- Test the isolation: Whatever the model, Microsoft recommends testing that no data leaks from one tenant to another (Microsoft, Jun 27, 2025). At Level 2 and above, the OWASP Application Security Verification Standard (ASVS) 5.0 requires controls that prevent one tenant’s operations from affecting other tenants (OWASP, May 30, 2025).
What is multi-tenancy called in German?
In German, multi-tenancy is called “Mandantenfähigkeit,” and a tenant is a “Mandant.” Software that can keep tenants apart is “mandantenfähig.” In their German documentation, Microsoft also writes “mehrinstanzenfähig” for multitenant, and Google writes “Mehrmandantenfähigkeit.”
Germany’s data protection authorities define the terms in their Standard Data Protection Model. There, IT counts as mandantenfähig if it can implement the necessary separation between tenants, and the separate processing is called Mandantentrennung, which translates as tenant isolation (German Data Protection Conference, in German).
In everyday German, a Mandant is the client of a lawyer or, more generally, a customer or principal (Duden, in German). SAP uses the word for a unit that is self-contained in terms of business, organization and data, with its own master data, transaction data and user data (SAP, in German). SAP’s English documentation calls this unit a client (SAP Learning).
Vendors translate the English terms in different ways. Microsoft’s German documentation calls tenants Mandanten but multitenant solutions mehrinstanzenfähig (Microsoft, in German). Google’s German documentation uses Mehrmandantenfähigkeit (Google Cloud, in German).
How is multi-tenancy different from single-tenancy and user roles?
Multi-tenancy separates customers from each other. Roles and permissions control what individual people within a tenant may see and do. In a single-tenant deployment, each customer gets its own installation. Underneath the software, the cloud provider also separates the computing, storage and network resources of its customers.
The numbers in the “Source” column refer to the list of sources at the end of this article.
| Term | What is separated | Who separates it | Example | Source |
|---|---|---|---|---|
| Multi-tenancy | data, users and settings of different customers in one shared application | the application and the database | appointment software used by many medical practices | 3, 19 |
| Single-tenant deployment | everything, because each customer has its own installation | the operations team, which sets up and maintains each installation separately | cloud software for law firms that require dedicated infrastructure | 4 |
| Roles and permissions | what individual people within a tenant may see and do | the application’s permission model | Back-office staff see orders; only accounting sees invoices. | 3, 7 |
| Tenant isolation in the cloud | computing, storage and network resources that a cloud provider’s customers share | the cloud provider | virtual servers of different companies on the same hardware | 23 |
Tenant isolation and roles complement each other: within each tenant, the software needs its own roles and permissions. According to the Standard Data Protection Model, each tenant should be able to define its own roles, and no function may grant permissions across a tenant’s boundary (German Data Protection Conference, Oct 6, 2020).
What do German authorities expect from multi-tenant software?
Under the Standard Data Protection Model of Germany’s data protection authorities, every tenant must be self-contained: no processing step may access another tenant’s data. Technical measures must ensure this; organizational rules alone aren’t enough. The degree of separation depends on the need for protection. For cloud services, the BSI, Germany’s federal cybersecurity authority, sets separation criteria in C5:2026.
The details are in module 50, “Trennen” (separation), of the Standard Data Protection Model. Version 1.0 dates from October 6, 2020 (German Data Protection Conference, in German). The Data Protection Conference (DSK) of Germany’s federal and state data protection authorities, or its technical working group, has released the module for use. It’s available only in German, while the SDM method itself is also published in English (SDM page, in German). According to the module, separation serves the GDPR requirements of purpose limitation, data minimization, confidentiality and erasure (Article 5(1)(b), (c) and (f) and Article 17(1) GDPR). Its key requirements:
- Every item of personal data belongs to exactly one tenant.
- Each tenant has its own permission system, configurable usage logging and logging of administrative actions.
- Functions that manage all tenants generally don’t process any tenant’s personal data, and their use is logged in a tamper-proof way.
- When processing on behalf of a tenant ends, its data can be returned and deleted without affecting other tenants.
- If the need for protection is high, physical separation may be necessary, up to and including dedicated hardware.
For cloud services, the Federal Office for Information Security (BSI) covers multi-tenancy in more detail in C5:2026 than in earlier versions of its criteria catalog. C5:2026 has been final since the end of March 2026, and the BSI also publishes it in English (BSI, C5:2026 page). Under these criteria, providers set policies and procedures for separating customer data, and they separate that data securely and strictly on shared resources, based on a risk assessment (criteria OPS-30 and OPS-31). If the effectiveness of the separation can’t be assessed with reasonable assurance, evidence can also come from expert third-party reviews such as penetration tests (BSI, C5:2026). An auditor can confirm whether a provider meets the criteria (BSI, C5 overview).
From our work: securing shared tables in PostgreSQL
In the discovery sprint, we decide with you how your SaaS product will keep its customers’ data apart. For this article, we’ve worked through an example of the model with the lowest cost per tenant: shared tables in PostgreSQL with a row-level security policy that the database itself enforces on every query. The diagram and the table first show what the three models share and what they keep separate per tenant.
| Model | Shared by all tenants | Separate per tenant | AWS term |
|---|---|---|---|
| Shared tables | application, database, tables | rows, identified by the tenant ID | pool |
| Separate schema | application, database | schema with its own set of tables | bridge |
| Separate database | application, often the database server too | database | bridge; with a dedicated server per tenant, silo |
In the example, every row in the orders table carries the ID of its tenant. For reads and writes alike, the policy allows only rows of the tenant that the current transaction has set (PostgreSQL 18, CREATE POLICY).
-- Every row belongs to exactly one tenant.
CREATE TABLE orders (
tenant_id uuid NOT NULL,
id uuid NOT NULL DEFAULT gen_random_uuid(),
title text NOT NULL,
PRIMARY KEY (tenant_id, id)
);
-- The policy applies to all commands, even for the table owner.
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
ALTER TABLE orders FORCE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
USING (tenant_id = current_setting('app.tenant_id')::uuid);
-- The application signs in with a role without special privileges;
-- the authentication method depends on your environment.
CREATE ROLE app_user LOGIN NOSUPERUSER NOBYPASSRLS;
GRANT SELECT, INSERT, UPDATE, DELETE ON orders TO app_user;-- In every transaction, set the tenant first.
-- true means the value applies only until the end of this transaction.
BEGIN;
SELECT set_config('app.tenant_id', '11111111-1111-1111-1111-111111111111', true);
SELECT title FROM orders; -- only the orders of this tenant
COMMIT;
-- Test 1: In the context of tenant A, no row of tenant B is visible.
BEGIN;
SELECT set_config('app.tenant_id', '11111111-1111-1111-1111-111111111111', true);
SELECT count(*) FROM orders
WHERE tenant_id = '22222222-2222-2222-2222-222222222222'; -- expected: 0
ROLLBACK;
-- Test 2: The role of the application does not bypass any policy.
SELECT rolsuper, rolbypassrls FROM pg_roles WHERE rolname = current_user; -- expected: f, f
-- Test 3: Find tables without an enforced row-level security policy.
SELECT relname FROM pg_class
WHERE relkind = 'r' AND relnamespace = 'public'::regnamespace
AND NOT (relrowsecurity AND relforcerowsecurity);What to watch out for:
- Privileged roles: Superusers and roles with
BYPASSRLSbypass every row-level security policy, and so does a table’s owner withoutFORCE(PostgreSQL 18, row security policies). For normal requests, the application therefore uses a role without special privileges, and migrations run under a separate role (OWASP, as of Nov 5, 2026). - Tenant per transaction: If no tenant has been set in the session, the query fails with an error instead of returning rows (PostgreSQL 18, administration functions). With
true, the value applies only until the end of the transaction, as withSET LOCAL(PostgreSQL 18, SET). That way, a reused connection from the pool doesn’t inherit another tenant (OWASP, as of Nov 5, 2026). - Keys per tenant: Uniqueness and foreign key checks bypass row-level security, and PostgreSQL warns that they can leak information about other rows this way (PostgreSQL 18). That’s why the tenant ID is part of the primary key in the example.
- Testing with the real role: A test with a different role than in production can make a correct policy look broken or miss a bypass. Test with the same role and the same connection pool as in production, and check every table that Test 3 lists: either it’s shared on purpose, or it needs a policy (OWASP, as of Nov 5, 2026).
We ran both blocks on November 8, 2026, in a test database: PostgreSQL 18.6 in PGlite 0.5.9, with three test rows for two tenants. We created the rows as a superuser and then ran the queries under the app_user role (SET ROLE). Test 1 returned 0, Test 2 returned f and f, and Test 3 found no table. In the context of tenant A, the query read only that tenant’s row, and the database rejected a new row for tenant B. With no tenant set, the query failed with an error.
The examples are free to use under the MIT-0 license, without crediting us. Every command follows the PostgreSQL 18 documentation.
Frequently asked questions
Can existing software be made multi-tenant later?
Yes, but it takes work. Every table with customer data gets a tenant ID, existing data is assigned to a tenant, and every query, cache and file store is checked for tenant scoping. Microsoft notes that switching to a different model later is sometimes costly, so it pays to plan for the tenant ID from the start.
How much does multi-tenancy cost?
There’s no fixed price. The tenant isolation model is one of the factors that determine the price of a SaaS product. As a rule, the stronger the isolation, the higher the cost per tenant and the operating effort. Our cost guides How much does it cost to build a SaaS product? and How much does custom software development cost? give price ranges in euros.