Definition
Mandantenfähigkeit ist die Fähigkeit einer Software, mehrere Kunden, die Mandanten, aus einer gemeinsamen Installation zu bedienen. Jeder Mandant sieht und ändert nur seine eigenen Daten, Benutzer und Einstellungen. Getrennt werden die Daten über eine eigene Datenbank, ein eigenes Schema oder eine Mandantenkennung in gemeinsamen Tabellen. Englisch heißt das Multi-Tenancy.
Das Wichtigste in Kürze
- Mandantenfähige Software bedient viele Kunden aus einer Installation. Jeder Kunde sieht nur seine eigenen Daten, Benutzer und Einstellungen.
- In der Datenbank gibt es drei Grundmodelle: gemeinsame Tabellen mit Mandantenkennung, ein eigenes Schema oder eine eigene Datenbank je Kunde.
- Gemeinsame Tabellen kosten am wenigsten. Eigene Datenbanken trennen klarer, machen Sicherung und Löschung je Kunde einfacher und kosten mehr.
- Fehlerhafte Zugriffskontrolle steht bei OWASP auf Platz 1. In mandantenfähiger Software kann sie Daten eines Kunden für andere sichtbar machen.
- Nach dem Standard-Datenschutzmodell der Aufsichtsbehörden muss die Trennung technisch umgesetzt sein. Je höher der Schutzbedarf, desto stärker die Trennung.
Was ist ein Mandant?
Ein Mandant ist ein Kunde, für den eine Software einen abgeschlossenen Bereich führt, mit eigenen Daten, Benutzern und Einstellungen. In einer SaaS (Software as a Service) ist das meist eine Kundenfirma mit vielen Mitarbeitenden. Was alle Mandanten gleich brauchen, etwa den Programmcode oder eine Liste der Länder, teilen sie sich.
Im Alltag ist ein Mandant der Klient einer Anwältin oder eines Anwalts, allgemein ein Kunde oder Auftraggeber (Duden). In der IT bezeichnet das Wort eine abgeschlossene Einheit im System. SAP etwa beschreibt einen Mandanten als betriebswirtschaftlich, organisatorisch und datentechnisch in sich geschlossen, mit eigenen Stamm-, Bewegungs- und Benutzerdaten (SAP).
Die deutschen Datenschutzbehörden nennen in ihrem Standard-Datenschutzmodell den abgeschlossenen Bereich, in dem ein Verantwortlicher Daten hält und verarbeitet, einen Mandanten (Datenschutzkonferenz, 06.10.2020). Das können Kundenfirmen eines Softwareanbieters sein, aber auch die Krankenhäuser eines Klinikverbunds, die Informationstechnik gemeinsam nutzen und Patientendaten trotzdem getrennt verarbeiten müssen. Ein Kunde kann auch mehrere Mandanten brauchen, etwa getrennt für Entwicklung und Betrieb (Microsoft, 27.06.2025).
Dieser Beitrag erklärt vor allem die Sicht des Anbieters, der viele Kundenfirmen aus einer Software bedient. Auf Mandantenfähigkeit beruhen die meisten SaaS-Angebote, laut Google womöglich alle (Google Cloud, 26.10.2026). Wie SaaS insgesamt funktioniert, erklärt unser Leitfaden Was ist SaaS?
Wann ist Mandantenfähigkeit für Ihr Unternehmen wichtig?
Mandantenfähigkeit wird für Ihr Unternehmen wichtig, sobald eine Software die Daten mehrerer Firmen oder Bereiche getrennt halten muss. Das ist der Fall, wenn Sie Software an andere Firmen vermieten, ein eigenes Werkzeug zum Produkt machen oder mehrere Gesellschaften in einem System führen. Kaufen Sie eine SaaS ein, sollten Sie die Trennung beim Anbieter erfragen.
- Sie bauen eine SaaS: Das Mandantenmodell gehört zu den ersten Entscheidungen der Architektur. Ein späterer Wechsel des Modells ist laut Microsoft mitunter teuer (Microsoft, 21.08.2025). Bei uns fällt die Entscheidung gemeinsam mit Ihnen im Discovery-Sprint vor der Entwicklung, siehe SaaS-Entwicklung.
- Ihr eigenes Werkzeug soll ein Produkt werden: Dann braucht jeder Datensatz eine Zuordnung zu genau einem Mandanten, wie es das Standard-Datenschutzmodell der Aufsichtsbehörden für personenbezogene Daten vorsieht (Datenschutzkonferenz, 06.10.2020). Nachrüsten heißt: jede Abfrage, jeden Zwischenspeicher und jede Dateiablage auf den Mandanten prüfen (OWASP, Stand 05.11.2026).
- Sie führen mehrere Gesellschaften oder Standorte in einem System: Dann können die Gesellschaften Mandanten einer gemeinsamen Verwaltungssoftware sein, jede mit eigenen Benutzern und Rollen. Das Standard-Datenschutzmodell sieht dafür unter anderem getrennte Systeme zur Vergabe der Berechtigungen vor.
- Sie kaufen eine SaaS ein: Fragen Sie, nach welchem Modell der Anbieter trennt, wer die Trennung geprüft hat und ob er die Daten Ihrer Firma einzeln zurückspielen, herausgeben und löschen kann. Ob Kauf oder eigene Entwicklung besser passt, vergleicht unser Beitrag Individual- oder Standardsoftware.
Wie trennt eine Software die Daten ihrer Mandanten?
In der Datenbank gibt es drei Grundmodelle. Im ersten teilen sich alle Mandanten die Tabellen, und jede Zeile trägt eine Mandantenkennung. Im zweiten bekommt jeder Mandant ein eigenes Schema, also einen eigenen Satz Tabellen in derselben Datenbank. Im dritten bekommt er eine eigene Datenbank. Die Anwendung teilen sich in allen drei Modellen alle Mandanten.
Die Zahlen in der Spalte „Quelle“ sind die Nummern der Quellenliste am Ende des Beitrags.
| Modell | So wird getrennt | Stärken | Schwächen | Quelle |
|---|---|---|---|---|
| Gemeinsame Tabellen | Jede Zeile trägt die Kennung ihres Mandanten. Anwendung und Datenbank filtern jeden Zugriff danach. | Geringste Kosten je Mandant. Neue Mandanten brauchen keine neue Infrastruktur. Auswertungen über alle Mandanten sind einfach. | Ein Fehler in einer Abfrage kann fremde Daten zeigen. Einen einzelnen Mandanten wiederherzustellen ist aufwendig. Jede Änderung trifft alle Mandanten zugleich. | 8, 9, 6 |
| Eigenes Schema je Mandant | Jeder Mandant hat einen eigenen Satz Tabellen in derselben Datenbank. Datenbankrollen regeln, wer welches Schema lesen darf. | Anpassungen je Mandant sind möglich. Gemeinsame Daten der Anwendung können in einem gemeinsamen Schema liegen. | Schemas sind nicht starr getrennt: Wer die Rechte hat, liest auch andere Schemas. Jede Änderung am Datenmodell läuft durch alle Schemas. | 8, 10, 7 |
| Eigene Datenbank je Mandant | Jeder Mandant hat eine eigene Datenbank, auf einem gemeinsamen oder einem eigenen Datenbankserver. | Klare Grenze je Datenbank. Sicherung, Wiederherstellung und Löschung betreffen nur diesen Mandanten. Anpassungen je Mandant sind möglich. | Höhere Kosten je Mandant. Änderungen müssen automatisiert in jede Datenbank laufen. Auswertungen über alle Mandanten sind aufwendig. | 8, 9, 6 |
Zwischen den Modellen gibt es Stufen. Eigene Tabellen je Mandant in einer Datenbank, etwa mit einem Präfix im Tabellennamen, nennt das Standard-Datenschutzmodell als Zwischenstufe (Datenschutzkonferenz, 06.10.2020). Microsoft rät davon ab: Eine Datenbank trägt so keine große Zahl von Mandanten, und Abfragen, Verwaltung und Updates werden immer schwieriger (Microsoft, 21.08.2026).
Am stärksten trennt eine eigene Installation je Mandant, mit eigener Anwendung und eigener Datenbank. Streng genommen ist das Single-Tenant-Betrieb, denn die Mandanten teilen sich keine Installation. Die Kosten wachsen dabei mit jedem Kunden: Kostet die Infrastruktur für einen Mandanten einen bestimmten Betrag, kosten 100 Mandanten laut Microsoft wahrscheinlich das Hundertfache (Microsoft, 27.06.2025).
Mischformen sind üblich. In der Dokumentation von AWS heißen die Grundformen Pool für geteilte Ressourcen, Silo für eigene Ressourcen je Mandant und Bridge für Formen dazwischen (AWS, Silo, Pool und Bridge). Für PostgreSQL zählt AWS ein eigenes Schema oder eine eigene Datenbank auf einem gemeinsamen Server zur Bridge und einen eigenen Server je Mandant zum Silo (AWS, Entscheidungsmatrix).
Wann lohnt sich welches Modell?
Gemeinsame Tabellen lohnen sich bei vielen Mandanten mit wenig Daten je Mandant. Eigene Schemas passen zu einer mittleren Zahl von Mandanten, eigene Datenbanken zu Fällen, in denen die Trennung im Vordergrund steht. Einen eigenen Server je Mandant braucht, wer sehr große, leistungskritische Mandanten hat oder die Ressourcen je Mandant voll steuern muss. Die Wahl ist auch eine kaufmännische Entscheidung.
So ordnet AWS die Modelle für PostgreSQL ein (AWS, Entscheidungsmatrix). Microsoft betont, dass die Wahl auch von Ihren Geschäftszielen abhängt und davon, welche Formen der Trennung Ihre Kunden akzeptieren (Microsoft, 27.06.2025). Diese Fragen helfen bei der Entscheidung. Die Zahlen in der Spalte „Quelle“ sind die Nummern der Quellenliste am Ende des Beitrags.
| Frage | Spricht für gemeinsame Tabellen | Spricht für eigene Datenbank oder eigenen Server | Quelle |
|---|---|---|---|
| Wie viele Mandanten, wie groß? | viele Mandanten mit wenig Daten | wenige, sehr große Mandanten | 8 |
| Verlangen Kunden eigene Schlüssel, eigene Sicherungsregeln oder einen bestimmten Speicherort? | nein | ja | 9 |
| Braucht ein Mandant eigene Felder oder Indizes? | selten; eigene Felder liegen dann in einer eigenen Tabelle | häufig | 8, 9 |
| Wie oft werten Sie über alle Mandanten aus? | häufig | selten | 8 |
| Bremst die Last einzelner Mandanten die anderen? | Last ist gleichmäßig verteilt | einzelne Mandanten erzeugen hohe Last | 12, 4 |
| Müssen Sie einzelne Mandanten oft oder schnell wiederherstellen? | nein | ja | 8, 9 |
| Wie viel Betrieb können Sie automatisieren? | wenig | Updates, Sicherungen und Überwachung laufen automatisiert | 4, 9 |
Sie müssen sich nicht für alle Mandanten gleich entscheiden. Microsoft beschreibt ein Mischmodell: Kunden in der Testphase teilen sich eine Datenbank, Kunden eines Premium-Tarifs bekommen eine eigene. Alle Datenbanken tragen dabei die Mandantenkennung, deshalb lassen sich Mandanten jederzeit verschieben (Microsoft, 21.08.2025). Für ein erstes Produkt ist das nach unserer Einschätzung oft ein guter Start: gemeinsame Tabellen mit Mandantenkennung, abgesichert durch eine Zeilenrichtlinie der Datenbank, und für große Kunden später eine eigene Datenbank.
Welche Sicherheitsrisiken hat eine mandantenfähige Software?
Kritisch ist vor allem, dass ein Mandant Daten eines anderen sieht oder ändert. AWS nennt jede solche Grenzverletzung ein erhebliches, womöglich nicht mehr gutzumachendes Ereignis für einen SaaS-Anbieter. Dazu kommen geteilte Zwischenspeicher und Dateiablagen ohne Mandantenbezug und einzelne Mandanten, deren Last die anderen ausbremst.
Für AWS gehört die Mandantentrennung zu den Grundthemen jedes SaaS-Anbieters (AWS, Mandantentrennung). Zugriffsfehler sind verbreitet: In den Daten für die OWASP Top 10:2025 hatten 100 % der getesteten Anwendungen eine Form fehlerhafter Zugriffskontrolle, die Kategorie steht wieder auf Platz 1 (OWASP, 2025). Ein Beispiel von OWASP: Auf einer Plattform für Onlineshops ersetzt ein Angreifer in der Adresse der Umsatzdaten den Namen des Shops und sieht die Umsätze tausender Shops (OWASP, 2023).
So begrenzen Sie das Risiko:
- Mandanten auf dem Server bestimmen: Eine Mandantenkennung aus der Anfrage oder einem Header wählt den Mandanten nur aus. Ob der angemeldete Benutzer in diesem Mandanten und mit genau diesem Datensatz arbeiten darf, prüft der Server bei jedem Zugriff (OWASP, Stand 05.11.2026; OWASP, 2023).
- Eine zweite Sperre in der Datenbank: Zeilenrichtlinien (Row-Level Security) fangen eine vergessene Bedingung in einer Abfrage ab. Für gemeinsame Tabellen in PostgreSQL hält AWS sie für nötig (AWS, Zeilenrichtlinien). Microsoft nennt sie aufwendig in Planung, Umsetzung, Test und Pflege, viele mandantenfähige Anwendungen verzichten deshalb darauf (Microsoft, 21.08.2026). Außerdem können sie die Leistung beeinflussen (Microsoft, 07.07.2026).
- Auch außerhalb der Datenbank trennen: Zwischenspeicher, Dateiablagen, Warteschlangen und Protokolle brauchen ebenfalls den Bezug zum Mandanten (OWASP, Stand 05.11.2026).
- Last begrenzen: Leidet ein Mandant unter der Last eines anderen, spricht Microsoft vom Noisy-Neighbor-Problem (Microsoft, 11.06.2025). Dagegen helfen Grenzen je Mandant, etwa für Anfragen und Hintergrundaufgaben (OWASP, Stand 05.11.2026).
- Die Trennung testen: Microsoft rät, bei jedem Modell zu testen, dass keine Daten zu einem anderen Mandanten gelangen (Microsoft, 27.06.2025). Der Prüfstandard OWASP ASVS 5.0 verlangt ab Stufe 2 Kontrollen, die verhindern, dass Vorgänge eines Mandanten andere Mandanten berühren (OWASP, 30.05.2025).
Was bedeutet Multi-Tenancy?
Multi-Tenancy ist der englische Fachbegriff für Mandantenfähigkeit. Tenant heißt Mieter: Viele Mieter teilen sich ein Haus, jeder hat seine eigene Wohnung. Die Begriffsbestimmung ITU-T Y.3500 versteht unter Multi-Tenancy eine Zuteilung physischer oder virtueller Ressourcen, bei der die Mandanten mit ihren Berechnungen und Daten voneinander isoliert und füreinander unzugänglich sind.
Die Definition steht in der ITU-Empfehlung Y.3500 von 2014 (ITU-T). Das englische tenant bezeichnet eine Person, die Miete für Land oder ein Gebäude zahlt (Cambridge Dictionary). Das Bild vom Mietshaus nutzt auch Google: Die Mieter teilen sich Wasser- und Stromleitungen, aber jeder hat seine eigene Wohnung (Google Cloud). Weitere Begriffe aus Angeboten und Dokumentationen:
- Single-Tenant: eine Datenbank oder Installation für genau einen Mandanten (Microsoft, 21.08.2025).
- Noisy Neighbor: ein Mandant, dessen Last andere ausbremst (Microsoft, 11.06.2025).
- Silo, Pool, Bridge: die Namen bei AWS für eigene, geteilte und gemischte Ressourcen.
- Mehrinstanzenfähig: So übersetzt Microsoft multitenant in seiner deutschen Dokumentation (Microsoft). Google schreibt „Mehrmandantenfähigkeit“ (Google Cloud, deutsche Fassung).
Worin unterscheiden sich Mandantenfähigkeit, Rollen und Single-Tenant?
Mandantenfähigkeit trennt Kunden voneinander. Rollen und Rechte regeln, was einzelne Personen innerhalb eines Mandanten sehen und tun dürfen. Beim Single-Tenant-Betrieb bekommt jeder Kunde eine eigene Installation. Unterhalb der Software trennt der Cloud-Anbieter zusätzlich Rechner, Speicher und Netz seiner Kunden.
Die Zahlen in der Spalte „Quelle“ sind die Nummern der Quellenliste am Ende des Beitrags.
| Begriff | Was getrennt wird | Wer trennt | Beispiel | Quelle |
|---|---|---|---|---|
| Mandantenfähigkeit (Multi-Tenancy) | Daten, Benutzer und Einstellungen verschiedener Kunden in einer gemeinsamen Anwendung | Anwendung und Datenbank | eine Terminsoftware für viele Praxen | 3, 19 |
| Single-Tenant-Betrieb | alles, denn jeder Kunde hat eine eigene Installation | das Betriebsteam, das jede Installation einzeln aufsetzt und pflegt | Software für Kanzleien, deren Kunden eigene Infrastruktur verlangen | 4 |
| Rollen und Rechte | was einzelne Personen innerhalb eines Mandanten sehen und tun dürfen | das Berechtigungskonzept der Anwendung | Die Sachbearbeitung sieht Aufträge, nur die Buchhaltung sieht Rechnungen. | 3, 7 |
| Mandantentrennung in der Cloud | Rechner, Speicher und Netz, die sich die Kunden eines Cloud-Anbieters teilen | der Cloud-Anbieter | virtuelle Server verschiedener Firmen auf derselben Hardware | 23 |
Mandantentrennung und Rollen ergänzen sich: Innerhalb jedes Mandanten braucht die Software ein eigenes Rollenkonzept. Für jeden Mandanten sollen sich eigene Rollen festlegen lassen, und keine Funktion darf Rechte über die Grenze eines Mandanten hinweg vergeben (Datenschutzkonferenz, 06.10.2020).
Was verlangen Datenschutz und BSI von mandantenfähiger Software?
Nach dem Standard-Datenschutzmodell der deutschen Aufsichtsbehörden muss jeder Mandant abgeschlossen sein: Keine Verarbeitung greift auf Daten anderer Mandanten zu. Technische Maßnahmen müssen das verhindern, eine Anweisung allein reicht nicht. Wie stark getrennt wird, richtet sich nach dem Schutzbedarf. Für Cloud-Dienste beschreibt das Bundesamt für Sicherheit in der Informationstechnik (BSI) die Trennung im Kriterienkatalog C5:2026.
Ausführlich beschreibt das der Baustein 50 „Trennen“ des Standard-Datenschutzmodells, Version 1.0 vom 06.10.2020, den die Datenschutzkonferenz und ihr Arbeitskreis Technik zur Anwendung freigegeben haben (Datenschutzkonferenz, Maßnahmenkatalog). Er ordnet die Trennung der Zweckbindung, der Datenminimierung, der Vertraulichkeit und der Löschbarkeit zu (Art. 5 Abs. 1 lit. b, c und f, Art. 17 Abs. 1 DSGVO). Die wichtigsten Anforderungen:
- Jedes personenbezogene Datum gehört zu genau einem Mandanten.
- Jeder Mandant hat ein eigenes System für Berechtigungen, eine einstellbare Nutzungsprotokollierung und eine Protokollierung der Administration.
- Funktionen, die alle Mandanten verwalten, verarbeiten grundsätzlich keine personenbezogenen Daten eines Mandanten und werden revisionssicher protokolliert.
- Endet die Auftragsverarbeitung für einen Mandanten, lassen sich seine Daten herausgeben und löschen, ohne andere Mandanten zu berühren.
- Bei hohem Schutzbedarf kann eine physische Trennung nötig sein, bis hin zu eigener Hardware.
Für Cloud-Dienste behandelt das BSI die Mandantenfähigkeit im Kriterienkatalog C5:2026 ausführlicher als zuvor; der Katalog ist seit Ende März 2026 final (BSI, Seite zu C5:2026). Anbieter legen danach Richtlinien zur Trennung der Kundendaten fest und trennen sie auf gemeinsam genutzten Ressourcen sicher und strikt, gestützt auf eine Risikobeurteilung (OPS-30, OPS-31). Lässt sich die Wirksamkeit nicht sicher beurteilen, kann der Nachweis über Prüfungen Dritter wie Penetrationstests erfolgen (BSI, C5:2026). Ob ein Anbieter die Kriterien erfüllt, kann ein Wirtschaftsprüfer testieren (BSI, Kriterienkatalog C5).
Aus der Praxis: Gemeinsame Tabellen in PostgreSQL absichern
Im Discovery-Sprint legen wir mit Ihnen fest, wie Ihre SaaS die Daten ihrer Kunden trennt. Für diesen Beitrag haben wir das Modell mit den geringsten Kosten je Mandant als Beispiel ausgearbeitet: gemeinsame Tabellen in PostgreSQL mit einer Zeilenrichtlinie, die die Datenbank bei jeder Abfrage selbst anwendet. Das Diagramm und die Tabelle zeigen vorab, was in den drei Modellen geteilt und was je Mandant getrennt ist.
| Modell | Gemeinsam genutzt | Je Mandant getrennt | Name bei AWS |
|---|---|---|---|
| Gemeinsame Tabellen | Anwendung, Datenbank, Tabellen | Zeilen, erkennbar an der Mandantenkennung | Pool |
| Eigenes Schema | Anwendung, Datenbank | Schema mit eigenem Satz Tabellen | Bridge |
| Eigene Datenbank | Anwendung, oft auch der Datenbankserver | Datenbank | Bridge; mit eigenem Server je Mandant Silo |
Im Beispiel trägt jede Zeile der Tabelle auftraege die Kennung ihres Mandanten. Die Zeilenrichtlinie lässt beim Lesen wie beim Schreiben nur Zeilen des Mandanten zu, den die laufende Transaktion gesetzt hat (PostgreSQL 18, CREATE POLICY).
-- Jede Zeile gehört genau einem Mandanten.
CREATE TABLE auftraege (
mandant_id uuid NOT NULL,
id uuid NOT NULL DEFAULT gen_random_uuid(),
titel text NOT NULL,
PRIMARY KEY (mandant_id, id)
);
-- Die Richtlinie gilt für alle Befehle, auch für den Eigentümer der Tabelle.
ALTER TABLE auftraege ENABLE ROW LEVEL SECURITY;
ALTER TABLE auftraege FORCE ROW LEVEL SECURITY;
CREATE POLICY nur_eigener_mandant ON auftraege
USING (mandant_id = current_setting('app.mandant_id')::uuid);
-- Die Anwendung meldet sich mit einer Rolle ohne Sonderrechte an;
-- das Anmeldeverfahren richtet sich nach Ihrer Umgebung.
CREATE ROLE app_nutzer LOGIN NOSUPERUSER NOBYPASSRLS;
GRANT SELECT, INSERT, UPDATE, DELETE ON auftraege TO app_nutzer;-- In jeder Transaktion zuerst den Mandanten setzen.
-- true heißt: Der Wert gilt nur bis zum Ende dieser Transaktion.
BEGIN;
SELECT set_config('app.mandant_id', '11111111-1111-1111-1111-111111111111', true);
SELECT titel FROM auftraege; -- nur Aufträge dieses Mandanten
COMMIT;
-- Test 1: Im Kontext von Mandant A ist keine Zeile von Mandant B sichtbar.
BEGIN;
SELECT set_config('app.mandant_id', '11111111-1111-1111-1111-111111111111', true);
SELECT count(*) FROM auftraege
WHERE mandant_id = '22222222-2222-2222-2222-222222222222'; -- erwartet: 0
ROLLBACK;
-- Test 2: Die Rolle der Anwendung umgeht keine Richtlinie.
SELECT rolsuper, rolbypassrls FROM pg_roles WHERE rolname = current_user; -- erwartet: f, f
-- Test 3: Tabellen ohne erzwungene Zeilenrichtlinie finden.
SELECT relname FROM pg_class
WHERE relkind = 'r' AND relnamespace = 'public'::regnamespace
AND NOT (relrowsecurity AND relforcerowsecurity);Worauf es ankommt:
- Sonderrechte: Superuser und Rollen mit
BYPASSRLSumgehen jede Zeilenrichtlinie, der Eigentümer einer Tabelle ohneFORCEebenfalls (PostgreSQL 18, Zeilenrichtlinien). Für normale Anfragen nutzt die Anwendung deshalb eine Rolle ohne Sonderrechte, Migrationen laufen mit einer eigenen (OWASP, Stand 05.11.2026). - Mandant je Transaktion: Wurde in der Sitzung kein Mandant gesetzt, bricht die Abfrage mit einem Fehler ab, statt Zeilen zu liefern (PostgreSQL 18, Verwaltungsfunktionen). Mit
truegilt der Wert nur bis zum Ende der Transaktion, wie beiSET LOCAL(PostgreSQL 18, SET). So erbt eine wiederverwendete Verbindung aus dem Pool keinen fremden Mandanten (OWASP, Stand 05.11.2026). - Schlüssel je Mandant: Prüfungen auf Eindeutigkeit und Fremdschlüssel umgehen die Zeilenrichtlinie, und PostgreSQL warnt, dass sie so Informationen über fremde Zeilen verraten können (PostgreSQL 18). Im Beispiel gehört die Mandantenkennung deshalb zum Primärschlüssel.
- Mit der echten Rolle testen: Ein Test mit einer anderen Rolle als im Betrieb kann eine richtige Richtlinie fehlerhaft erscheinen lassen oder eine Umgehung übersehen. Testen Sie mit derselben Rolle und demselben Verbindungspool wie im Betrieb, und prüfen Sie jede Tabelle aus Test 3: Sie wird bewusst gemeinsam genutzt oder braucht eine Richtlinie (OWASP, Stand 05.11.2026).
Beide Blöcke haben wir am 08.11.2026 in einer Testdatenbank ausgeführt: PostgreSQL 18.6 in PGlite 0.5.9, mit drei Testzeilen für zwei Mandanten. Die Zeilen haben wir als Superuser angelegt, die Abfragen danach mit der Rolle app_nutzer gestellt (SET ROLE). Test 1 ergab 0, Test 2 ergab f und f, und Test 3 fand keine Tabelle. Im Kontext von Mandant A las die Abfrage nur dessen Zeile, eine neue Zeile für Mandant B lehnte die Datenbank ab. Ohne gesetzten Mandanten brach die Abfrage mit einem Fehler ab.
Die Beispiele dürfen Sie frei verwenden, sie stehen unter der Lizenz MIT-0. Jeder Befehl folgt der Dokumentation von PostgreSQL 18.
Häufige Fragen
Lässt sich eine bestehende Software nachträglich mandantenfähig machen?
Ja, aber mit Aufwand. Jede Tabelle mit Kundendaten bekommt eine Mandantenkennung, bestehende Daten werden einem Mandanten zugeordnet, und jede Abfrage, jeder Zwischenspeicher und jede Dateiablage wird auf den Mandanten geprüft. Weil ein späterer Wechsel des Modells laut Microsoft mitunter teuer ist, lohnt es sich, die Mandantenkennung von Anfang an einzuplanen.
Was kostet Mandantenfähigkeit?
Eine feste Summe gibt es nicht. Das Modell der Mandantentrennung gehört zu den Punkten, die den Preis einer SaaS bestimmen: Je stärker getrennt wird, desto höher sind in der Regel die Kosten je Mandant und der Aufwand im Betrieb. Preisspannen in Euro nennen unsere Kostenratgeber Was kostet ein SaaS-MVP? und Was kostet Software?