Wer Software als Dienst anbietet, steht früh vor einer Grundsatzfrage: Bekommt jeder Kunde seine eigene Installation, oder teilen sich alle Kunden ein System? Die erste Variante fühlt sich sicher an, wird aber bei jedem neuen Kunden teurer in Betrieb und Wartung. Multi-Tenancy — Mandantenfähigkeit — bedient viele Kunden aus einer Codebasis und einer Infrastruktur, bei strikt getrennten Daten.
Die drei Isolationsmodelle
Mandantentrennung lässt sich auf mehreren Ebenen umsetzen. Die Wahl bestimmt Kosten, Isolationsgrad und Betriebsaufwand.
- Getrennte Datenbank je Mandant: stärkste Isolation, einfaches Löschen einzelner Kunden, aber höchster Betriebsaufwand.
- Gemeinsame Datenbank, getrennte Schemata: mittlerer Weg mit guter Trennung und moderaten Kosten.
- Gemeinsame Tabellen mit Tenant-ID: günstigste Skalierung, verlangt aber wasserdichte Zugriffsfilter in jeder Abfrage.
Der teuerste Fehler in Multi-Tenancy ist eine vergessene WHERE-Klausel. Ein Mandant, der die Daten eines anderen sieht, ist kein Bug — es ist ein Vertrauensbruch.
Datenisolation ist nicht verhandelbar
Bei geteilten Tabellen hängt die gesamte Trennung an der konsequenten Filterung nach Tenant-ID. Wird sie an einer einzigen Stelle vergessen, sieht ein Kunde fremde Daten. Deshalb gehört der Mandantenfilter nicht in jede einzelne Abfrage von Hand, sondern in eine zentrale Schicht — etwa über Row-Level-Security der Datenbank oder einen erzwungenen Query-Scope im Datenzugriff. Sicherheit, die von Disziplin einzelner Entwickler abhängt, versagt irgendwann.
Wo Multi-Tenancy Geld spart
Ein System statt hundert bedeutet: ein Deployment, ein Monitoring, ein Update. Neue Funktionen erreichen alle Kunden gleichzeitig, Sicherheitslücken werden einmal geschlossen. Die Infrastrukturkosten pro Kunde sinken, weil sich Ressourcen teilen lassen. Genau das macht wiederkehrende Einnahmen bei gedeckelten Betriebskosten möglich — die Grundrechnung jedes profitablen SaaS.
Die Grenzen kennen
Multi-Tenancy passt nicht überall. Kunden mit strengen Compliance-Anforderungen verlangen manchmal physische Datentrennung. Ein einzelner sehr großer Mandant kann die Ressourcen der anderen beeinträchtigen — das Noisy-Neighbor-Problem, dem man mit Limits und Priorisierung begegnet. Eine tragfähige Architektur erlaubt deshalb oft Mischformen: die Masse teilt sich ein System, einzelne Großkunden bekommen eine isolierte Instanz.
Von Anfang an einplanen
Mandantenfähigkeit nachträglich in ein System einzuziehen, das für einen einzigen Kunden gebaut wurde, ist teuer und riskant. Wer von Beginn an mit Tenant-Kontext, zentraler Isolation und mandantenbewusstem Logging arbeitet, spart sich den schmerzhaften Umbau, sobald der zweite und dritte Kunde kommt.