Skip to content
DeutschBook an intro call

Explainer · SaaS & software

What is a multi-tenant SaaS architecture?

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.

Three data isolation models compared, as of November 2026
ModelHow data is separatedStrengthsWeaknessesSource
Shared tablesEvery 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 tenantEach 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 tenantEach 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.

When each model fits, as of November 2026
QuestionFavors shared tablesFavors a separate database or serverSource
How many tenants, and how large?many tenants with little data eacha few very large tenants8
Do customers require their own encryption keys, their own backup rules or a specific storage location?noyes9
Does a tenant need its own fields or indexes?rarely; custom fields then go in a separate tableoften8, 9
How often do you report across all tenants?oftenrarely8
Does the load of individual tenants slow down the others?load is evenly spreadindividual tenants create heavy load12, 4
Do you need to restore individual tenants often or quickly?noyes8, 9
How much of your operations can you automate?littleupdates, backups and monitoring run automatically4, 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.

Multi-tenancy and related terms
TermWhat is separatedWho separates itExampleSource
Multi-tenancydata, users and settings of different customers in one shared applicationthe application and the databaseappointment software used by many medical practices3, 19
Single-tenant deploymenteverything, because each customer has its own installationthe operations team, which sets up and maintains each installation separatelycloud software for law firms that require dedicated infrastructure4
Roles and permissionswhat individual people within a tenant may see and dothe application’s permission modelBack-office staff see orders; only accounting sees invoices.3, 7
Tenant isolation in the cloudcomputing, storage and network resources that a cloud provider’s customers sharethe cloud providervirtual servers of different companies on the same hardware23

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.

Tenants are separated at the row, schema or database level
Tenants are separated at the row, schema or database level In all three models, the tenants share one application. With shared tables, the rows of all tenants are in the same tables, and every row carries the ID of its tenant. With a separate schema, each tenant has its own schema in the same database. With a separate database, each tenant has its own database, often on a shared database server. The table below shows what all tenants share and what’s separate per tenant. Shared tables One application for all tenants One database Table for all tenants Row with tenant ID A Row with tenant ID B Row with tenant ID C Separate schema per tenant One application for all tenants One database Schema Tenant A Schema Tenant B Schema Tenant C Separate database per tenant One application for all tenants Often a shared database server Database Tenant A Database Tenant B Database Tenant C
Three models: what all tenants share and what’s separate per tenant
ModelShared by all tenantsSeparate per tenantAWS term
Shared tablesapplication, database, tablesrows, identified by the tenant IDpool
Separate schemaapplication, databaseschema with its own set of tablesbridge
Separate databaseapplication, often the database server toodatabasebridge; 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).

PostgreSQL: table with a tenant ID and a row-level security 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;
PostgreSQL: set the tenant per transaction and test the isolation
-- 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 BYPASSRLS bypass every row-level security policy, and so does a table’s owner without FORCE (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 with SET 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.

Sources

  1. Duden online: Mandant (in German). Accessed .
  2. SAP Learning: Die Datenstruktur eines AS ABAP-basierten SAP-Systems beschreiben (in German). Accessed .
  3. German Data Protection Conference (DSK): Baustein 50 „Trennen“, Version 1.0, Standard-Datenschutzmodell (in German). . Accessed .
  4. Microsoft, Azure Architecture Center: Tenancy models for a multitenant solution. . Accessed .
  5. Google Cloud: Implement multi-tenancy in Spanner. . Accessed .
  6. Microsoft, Azure SQL Database: Multitenant SaaS database tenancy patterns. . Accessed .
  7. OWASP Cheat Sheet Series: Multi-Tenant Application Security Cheat Sheet. . Accessed .
  8. AWS Prescriptive Guidance: Decision matrix (Implementing managed PostgreSQL for multi-tenant SaaS applications on AWS). Accessed .
  9. Microsoft, Azure Architecture Center: Architectural approaches for storage and data in multitenant solutions. . Accessed .
  10. PostgreSQL Global Development Group: 5.10. Schemas. Version 18. Accessed .
  11. AWS Well-Architected: Silo, Pool, and Bridge Models (SaaS Lens). . Accessed .
  12. Microsoft, Azure Architecture Center: Noisy Neighbor antipattern. . Accessed .
  13. AWS Well-Architected: Tenant Isolation (SaaS Lens). . Accessed .
  14. OWASP Top 10:2025: A01:2025 Broken Access Control. 2025. Accessed .
  15. OWASP API Security Top 10: API1:2023 Broken Object Level Authorization. 2023. Accessed .
  16. AWS Prescriptive Guidance: Row-level security recommendations. Accessed .
  17. Microsoft, Azure Architecture Center: Guidance for using Azure Database for PostgreSQL in a multitenant solution. . Accessed .
  18. OWASP: Application Security Verification Standard 5.0.0, V8 Authorization. . Accessed .
  19. International Telecommunication Union (ITU-T): Recommendation ITU-T Y.3500: Cloud computing – Overview and vocabulary. . Accessed .
  20. Cambridge Dictionary: tenant. Accessed .
  21. Microsoft Learn: Mehrinstanzenfähigkeitsmodelle für eine mehrinstanzenfähige Lösung (in German). . Accessed .
  22. Google Cloud: Mehrmandantenfähigkeit in Spanner implementieren (in German). . Accessed .
  23. Federal Office for Information Security (BSI): Cloud Computing Compliance Criteria Catalogue (C5:2026), version 1.0.2. 2026. Accessed .
  24. State Commissioner for Data Protection and Freedom of Information, Mecklenburg-Western Pomerania: Standard-Datenschutzmodell: Methode und Maßnahmenkatalog (in German). Accessed .
  25. Federal Office for Information Security (BSI): C5:2026. Accessed .
  26. Federal Office for Information Security (BSI): C5 criteria catalogue. Accessed .
  27. PostgreSQL Global Development Group: CREATE POLICY. Version 18. Accessed .
  28. PostgreSQL Global Development Group: 5.9. Row Security Policies. Version 18. Accessed .
  29. PostgreSQL Global Development Group: 9.28. System Administration Functions. Version 18. Accessed .
  30. PostgreSQL Global Development Group: SET. Version 18. Accessed .
  31. SAP Learning: Describing the Data Structure of an AS ABAP Based SAP System. Accessed .

Editorial note

Researched and drafted with AI assistance. Mohammad Alboush has not yet checked the sources, figures and claims.

Content not yet reviewed

Changes to this article

DateTypeChange
First publicationArticle published
CorrectionCopyedited references, punctuation and terms. The statements remain the same.

Spotted a mistake? Email us at kontakt@datafalke.de. We’ll fix it and log the change.

Your next step

What would your MVP cost?

A discovery sprint pins down the core features, architecture and risks; then we quote a fixed price.

Menu

Book an intro callDeutsch