Mehrmandantenfähigkeit einfach erklärt: was Multi-Tenancy bedeutet

Sobald eine SaaS-Anwendung mehr als einen Kunden bedient, taucht früher oder später der Begriff Mehrmandantenfähigkeit auf – gemeint ist die Fähigkeit, mehrere voneinander getrennte Kunden auf derselben Software laufen zu lassen, ohne dass sie sich gegenseitig sehen oder beeinflussen.

Wie diese Trennung technisch umgesetzt wird, entscheidet über Kosten, Sicherheit und wie leicht sich die Anwendung später skalieren lässt. Die Entscheidung sollte früh im Projekt fallen, nicht erst, wenn der zehnte Kunde anklopft.

Was Mehrmandantenfähigkeit konkret bedeutet

Ein Mandant ist in diesem Zusammenhang meist ein Kunde oder eine Organisation, die die Anwendung mit ihren eigenen Daten, Nutzern und Einstellungen verwendet. Mehrmandantenfähig ist eine Anwendung, wenn sie beliebig viele solcher Mandanten sauber getrennt bedienen kann, ohne für jeden einzelnen eine eigene Installation zu brauchen.

Der Gegenentwurf ist eine Einzelinstanz je Kunde: jede Organisation bekommt eine komplett eigene, isolierte Installation der Software. Das ist einfacher zu verstehen, aber aufwendiger zu betreiben, sobald die Kundenzahl wächst.

Der Begriff „Mandant“ stammt ursprünglich aus der Buchhaltungs- und Steuersoftware, wo ein Berater mehrere Kundenfirmen in einem System verwaltet. In der SaaS-Welt hat sich der Begriff für dasselbe Grundprinzip übernommen: mehrere unabhängige Nutzergruppen in einem gemeinsamen System.

Getrennte Datenbanken je Mandant

Die strengste Form der Trennung ist eine eigene Datenbank pro Kunde. Das bietet die höchste Sicherheit gegen versehentliche Datenvermischung und erleichtert individuelle Anpassungen oder Exporte pro Kunde.

Der Nachteil: Mit steigender Kundenzahl wächst auch der Wartungsaufwand, weil jede Datenbank einzeln gesichert, aktualisiert und überwacht werden muss. Für Anwendungen mit besonders hohen Sicherheits- oder Compliance-Anforderungen ist dieser Mehraufwand aber oft gerechtfertigt.

Eine gemeinsame Datenbank mit logischer Trennung

Häufiger verbreitet ist eine gemeinsame Datenbank, in der jeder Datensatz über ein Mandanten-Kennzeichen einem bestimmten Kunden zugeordnet ist. Die Anwendung sorgt dafür, dass jede Abfrage automatisch nur die Daten des jeweils angemeldeten Mandanten zurückliefert.

Dieses Modell ist wirtschaftlicher im Betrieb, weil sich Wartung und Updates zentral erledigen lassen. Es stellt aber höhere Anforderungen an die Sorgfalt in der Entwicklung: Ein einziger übersehener Filter in einer Abfrage kann dazu führen, dass ein Kunde Daten eines anderen sieht.

Aus diesem Grund braucht dieses Modell konsequente Tests genau an dieser Stelle – nicht nur, ob Funktionen korrekt arbeiten, sondern ob sie unter keinen Umständen mandantenübergreifend Daten preisgeben.

Mischformen in der Praxis

Viele SaaS-Anbieter kombinieren beide Ansätze: eine gemeinsame Datenbank für die meisten Kunden und eine dedizierte, isolierte Umgebung für einzelne Großkunden mit besonderen Sicherheits- oder Compliance-Anforderungen. Das erlaubt wirtschaftlichen Betrieb im Regelfall und Flexibilität für Sonderfälle.

Diese Mischform ist technisch aufwendiger zu pflegen, weil beide Architekturen parallel funktionieren müssen. Sie lohnt sich meist erst, wenn tatsächlich konkrete Kunden mit entsprechenden Anforderungen vorhanden sind.

Wann Mehrmandantenfähigkeit von Anfang an nötig ist

Wenn dein Geschäftsmodell darauf ausgelegt ist, viele Kunden über dieselbe Anwendung zu bedienen – ein klassisches SaaS-Produkt also –, sollte die Mandantentrennung von Beginn an mitgedacht werden. Sie nachträglich in eine bestehende, für einen einzelnen Kunden gebaute Anwendung einzuziehen, ist deutlich aufwendiger als sie direkt einzuplanen.

Wer dagegen zunächst eine einzelne Individuallösung für einen Kunden baut und erst später ein SaaS-Produkt daraus machen will, sollte diesen Schritt beim Aufbau des SaaS-Fahrplans von vornherein einplanen.

Ein nachträglicher Umbau bedeutet in der Praxis meist, große Teile der Datenbankstruktur und der Zugriffslogik neu zu schreiben, während gleichzeitig der laufende Betrieb für den ersten Kunden nicht unterbrochen werden darf. Dieser doppelte Aufwand lässt sich vermeiden, wenn die Architektur von Anfang an auf mehrere Mandanten ausgelegt ist.

Auswirkungen auf Rechte und Rollen

Mehrmandantenfähigkeit betrifft nicht nur Datenbanken, sondern auch Rechte und Rollen: Ein Nutzer eines Mandanten darf üblicherweise nur Nutzer und Einstellungen innerhalb seines eigenen Mandanten verwalten, nie über Mandantengrenzen hinweg.

Diese Trennung muss auch bei administrativen Zugängen gelten, die für den Support oder die Betriebsführung genutzt werden. Ein Support-Zugang mit uneingeschränktem Zugriff auf alle Mandanten ist ein häufig unterschätztes Sicherheitsrisiko.

Wie du das passende Modell für dein Produkt findest

Die Entscheidung hängt von der erwarteten Kundenzahl, den Sicherheitsanforderungen deiner Zielgruppe und dem verfügbaren Entwicklungsbudget ab. Für die meisten kleinen SaaS-Produkte ist eine gemeinsame Datenbank mit sauberer logischer Trennung der wirtschaftlichste und ausreichend sichere Weg.

Wichtiger als die Wahl der Architektur selbst ist, dass die Entscheidung bewusst getroffen und im Datenbankdesign von Anfang an konsequent umgesetzt wird.

Eine einfache Faustregel: Wer nur wenige, sehr unterschiedliche Großkunden erwartet, tendiert eher zu getrennten Datenbanken. Wer viele ähnliche, kleinere Kunden gewinnen will, fährt mit einer gemeinsamen, logisch getrennten Datenbank in der Regel wirtschaftlicher.

Mehrmandantenfähigkeit und individuelle Anpassungen

Ein häufiger Konflikt entsteht, wenn einzelne Kunden individuelle Anpassungen wünschen, die Anwendung aber für alle Mandanten auf derselben Codebasis läuft. Jede kundenspezifische Sonderlösung erhöht die Komplexität und erschwert spätere Updates für alle übrigen Kunden.

Bewährt hat sich, individuelle Wünsche möglichst über konfigurierbare Einstellungen statt über eigenen Code pro Kunde zu lösen – etwa durch aktivierbare Funktionsmodule statt fest einprogrammierter Sonderfälle. So bleibt die gemeinsame Codebasis wartbar, während einzelne Mandanten trotzdem unterschiedlich konfiguriert sein können.

Lässt sich ein Kundenwunsch nicht über Konfiguration abbilden, ist das ein guter Anlass zu prüfen, ob dieser Kunde tatsächlich in die Mehrmandanten-Architektur passt oder eher eine gesonderte Lösung braucht.

Häufige Fragen