Multi-Tenancy, auf Deutsch Mandantenfähigkeit, ist ein zentrales architektonisches Konzept im SaaS. Es beschreibt eine Software-Architektur, bei der eine einzige Instanz einer Anwendung mehrere Kunden — die Mandanten oder Tenants — gleichzeitig bedient, während die Daten und Konfigurationen jedes Mandanten strikt von denen der anderen getrennt bleiben. Praktisch jedes moderne SaaS-Produkt beruht auf diesem Prinzip, weil es den effizienten Betrieb vieler Kunden auf einer gemeinsamen Infrastruktur erlaubt.
Warum Multi-Tenancy für SaaS entscheidend ist
Der wirtschaftliche Kern des SaaS-Modells ist die gemeinsame Nutzung von Infrastruktur. Würde jeder Kunde eine eigene, vollständig getrennte Installation der Software erhalten, wären Betrieb, Wartung und Updates so teuer, dass das Geschäftsmodell nicht funktionierte. Multi-Tenancy löst dieses Problem, indem alle Kunden dieselbe laufende Anwendung nutzen, während ihre Daten logisch getrennt bleiben. Ein einziges Update erreicht damit alle Kunden gleichzeitig, und die Betriebskosten verteilen sich auf viele Schultern. Diese Effizienz ist die ökonomische Grundlage, auf der SaaS überhaupt erst rentabel wird.
Modelle der Mandantentrennung
Es gibt verschiedene Ansätze, die Trennung der Mandanten technisch umzusetzen. Beim Modell der gemeinsamen Datenbank mit gemeinsamen Tabellen teilen sich alle Mandanten dieselben Tabellen, und jede Zeile trägt eine Kennung, die sie einem Mandanten zuordnet. Beim Modell der gemeinsamen Datenbank mit getrennten Schemata erhält jeder Mandant ein eigenes Datenbankschema. Beim Modell der getrennten Datenbanken bekommt jeder Mandant eine eigene Datenbank. Die Modelle unterscheiden sich in Isolationsgrad, Betriebsaufwand und Kosten: Mehr Trennung bedeutet stärkere Isolation, aber höheren Aufwand. Die meisten SaaS-Produkte wählen das erste Modell und sichern die Trennung über Mechanismen wie Row-Level-Security ab.
Sicherheit durch Row-Level-Security
Das grösste Risiko der Multi-Tenancy ist, dass ein Mandant versehentlich oder durch einen Angriff auf die Daten eines anderen Mandanten zugreift. Ein solcher Datenleck-Vorfall wäre für ein SaaS-Geschäft katastrophal. Eine wirksame Absicherung ist die Row-Level-Security auf Datenbankebene: Die Datenbank erzwingt selbst, dass jede Abfrage nur die Zeilen zurückgibt, die zum jeweiligen Mandanten gehören, unabhängig davon, was die Anwendung anfragt. Diese Sicherung auf der untersten Ebene ist robuster als eine reine Prüfung in der Anwendungslogik, weil sie auch dann greift, wenn die Anwendung einen Fehler enthält. Plattformen wie Supabase, die auf PostgreSQL beruhen, machen Row-Level-Security zu einem Kernbestandteil der Architektur.
Mandantentrennung in der Praxis
In einem typischen Multi-Tenant-SaaS gehört jeder Datensatz zu einem Mandanten, und die gesamte Architektur ist darauf ausgelegt, diese Zugehörigkeit konsequent durchzusetzen. Bei jeder Anfrage wird der Mandantenkontext bestimmt, und alle Datenbankzugriffe werden auf diesen Kontext beschränkt. Auch Hintergrundprozesse, Exporte und Berichte müssen diese Trennung respektieren. Ein häufiger Fehler entsteht, wenn ein neuer Programmteil die Mandantentrennung vergisst — etwa eine Auswertung, die versehentlich über alle Mandanten hinweg läuft. Deshalb ist es sicherer, die Trennung auf Datenbankebene zu erzwingen, statt sich auf die Disziplin jeder einzelnen Codestelle zu verlassen.
Anpassung pro Mandant
Multi-Tenancy betrifft nicht nur die Datentrennung, sondern auch die Anpassbarkeit. Verschiedene Mandanten haben oft unterschiedliche Konfigurationen, Funktionsumfänge oder Erscheinungsbilder. Eine gut gebaute Multi-Tenant-Architektur erlaubt solche Unterschiede, ohne den gemeinsamen Code zu verzweigen. Funktionsschalter steuern, welche Funktionen ein Mandant je nach Tarif sieht, und Konfigurationen pro Mandant erlauben individuelle Anpassungen. Diese Flexibilität auf gemeinsamer Codebasis ist eine Kunst für sich: Sie muss genug Spielraum für individuelle Bedürfnisse bieten, ohne in einen Wildwuchs zu münden, der die Wartung unmöglich macht.
Skalierung und Betrieb
Eine Multi-Tenant-Architektur muss mit der wachsenden Zahl der Mandanten und der ungleichen Last zwischen ihnen umgehen. Ein einzelner grosser Mandant darf die Leistung für alle anderen nicht beeinträchtigen. Mechanismen wie Ratenbegrenzung, gerechte Ressourcenverteilung und Überwachung der Last pro Mandant sorgen dafür, dass das System auch unter ungleicher Beanspruchung stabil bleibt. Bei sehr grossen Mandanten kann es sinnvoll werden, sie auf eine eigene Instanz auszulagern. Diese Betriebsfragen entscheiden über die Zuverlässigkeit eines SaaS und sollten von Anfang an mitbedacht werden, auch wenn sie erst mit dem Wachstum akut werden.
Der Bezug zu Datenschutz und Datenresidenz
Multi-Tenancy berührt unmittelbar den Datenschutz. Die strikte Trennung der Mandantendaten ist eine technische Voraussetzung dafür, die Daten verschiedener Kunden vertraulich zu behandeln, wie es die DSGVO und das revDSG verlangen. Zugleich stellt sich die Frage der Datenresidenz: Wo liegen die Daten aller Mandanten? Für DACH-Kunden ist EU- oder Schweiz-Hosting oft eine Bedingung. Eine durchdachte Multi-Tenant-Architektur berücksichtigt diese Anforderungen von Anfang an, statt sie nachträglich aufzusetzen. Innopulse baut Mandantenfähigkeit mit Row-Level-Security und EU-Hosting als Standard in jedes SaaS-Produkt ein, weil diese Grundlage über die Vertrauenswürdigkeit des gesamten Produkts entscheidet.
Fazit
Single-Tenancy als Gegenmodell
Das Gegenstück zur Multi-Tenancy ist die Single-Tenancy, bei der jeder Kunde eine eigene, vollständig getrennte Instanz der Anwendung erhält. Dieses Modell bietet die stärkste Isolation, weil die Daten und der Betrieb verschiedener Kunden physisch getrennt sind. Es ist jedoch deutlich teurer und aufwendiger, weil jede Instanz separat betrieben, gewartet und aktualisiert werden muss. Manche Anbieter setzen Single-Tenancy für besonders sicherheitskritische Grosskunden ein, während sie die Masse ihrer Kunden über Multi-Tenancy bedienen. Diese Mischform verbindet die Effizienz der Multi-Tenancy für die meisten Kunden mit der starken Isolation der Single-Tenancy für jene, die sie verlangen und bereit sind, dafür zu zahlen.
Die Bedeutung für Updates und Wartung
Ein oft unterschätzter Vorteil der Multi-Tenancy betrifft Updates und Wartung. Weil alle Kunden dieselbe laufende Anwendung nutzen, erreicht ein einziges Update sie alle gleichzeitig. Es gibt keine Versionsfragmentierung, bei der verschiedene Kunden unterschiedliche, teils veraltete Versionen einer Software betreiben — ein Problem, das bei On-Premise-Software die Wartung zur Qual macht. Sicherheitspatches, Fehlerbehebungen und neue Funktionen stehen sofort allen zur Verfügung. Diese einheitliche Codebasis senkt nicht nur die Betriebskosten, sondern erhöht auch die Sicherheit, weil es keine vergessenen, ungepatchten Altinstallationen gibt. Für den Anbieter bedeutet das eine erheblich vereinfachte Pflege, für den Kunden stets die aktuelle, sicherste Version.
Multi-Tenancy richtig planen
Die Entscheidung für ein bestimmtes Multi-Tenancy-Modell sollte früh und bewusst getroffen werden, weil sie schwer zu ändern ist, wenn eine Anwendung erst einmal wächst. Zu Beginn ist das Modell der gemeinsamen Tabellen mit Mandantenkennung und Row-Level-Security für die meisten SaaS-Produkte die richtige Wahl, weil es effizient und sicher ist. Wichtig ist, die Mandantentrennung von Anfang an konsequent durchzusetzen und auf der Datenbankebene zu verankern, statt sie der Anwendungslogik zu überlassen. Wer diese Grundlage solide legt, kann später bei Bedarf einzelne grosse Kunden auf eigene Instanzen auslagern, ohne die Architektur grundlegend umbauen zu müssen. Innopulse legt diese Grundlage in jedem Produkt von Anfang an, weil ein nachträglicher Umbau der Mandantentrennung zu den teuersten Fehlern im SaaS gehört.
Multi-Tenancy ist das unsichtbare Fundament fast jedes SaaS-Produkts. Sie ermöglicht die wirtschaftliche Effizienz des Modells, stellt aber hohe Anforderungen an die Sicherheit, weil die Trennung der Kundendaten lückenlos sein muss. Wer ein SaaS baut, sollte die Mandantenfähigkeit nicht als nachträgliches Detail, sondern als architektonische Grundentscheidung behandeln und die Trennung auf der robustesten verfügbaren Ebene erzwingen. Richtig umgesetzt, ist Multi-Tenancy unsichtbar und zuverlässig; falsch umgesetzt, wird sie zur grössten Schwachstelle eines SaaS-Geschäfts.