Multi-Tenancy in SaaS: Drei Wege und ihre echten Kosten

Was Multi-Tenancy bedeutet – und warum die Entscheidung früh fällt

Multi-Tenancy heißt: mehrere Kunden teilen sich eine Software-Instanz. Klingt trivial, ist es nicht. Die Frage, wie genau diese Trennung aussieht, fällt meist in den ersten Wochen eines Projekts – zu einem Zeitpunkt, an dem man noch wenig über die tatsächlichen Compliance-Anforderungen, den Kundenstamm und das Wachstumsszenario weiß.

Und sie bleibt. Die Tenancy-Strategie prägt die Datenzugriffsschicht, die Migrationsprozesse und die Betriebskosten für Jahre. Wer später wechseln will, baut die halbe Anwendung neu.

Hinter dem Schlagwort „mandantenfähig" stecken drei grundlegend verschiedene Architekturen. Jede hat ihre Berechtigung – und ihre Rechnung.

Die drei klassischen Architekturansätze

1. Gemeinsame Datenbank, gemeinsames Schema

Alle Mandanten teilen dieselben Tabellen. Jeder Datensatz bekommt eine tenant_id-Spalte – und die Anwendung stellt sicher, dass bei jeder Abfrage die richtige ID im WHERE-Clause steht.

Das ist der einfachste Einstieg: eine Datenbankverbindung, eine Migration, ein Backup. Wer früh live gehen will und den Betriebsaufwand niedrig halten muss, landet oft hier.

Die Kosten zeigen sich später:

Datenleck-Risiko: Jede fehlende WHERE tenant_id = ?-Bedingung ist ein potenzielles Datenleck. Das passiert – besonders in ORMs, die mehrere Abfragen zusammensetzen, oder in Reports, die über mehrere Tabellen joinen. Kein hypothetisches Szenario.
Noisy Neighbor: Ein Mandant mit einem schlecht geschriebenen Import-Job bremst alle anderen. Auf Datenbankebene gibt es keine Isolation, keine Bremse.
Compliance: Sobald ein Kunde Datenlokalisierung oder physische Trennung verlangt – in regulierten Branchen keine Seltenheit –, ist dieser Ansatz nicht mehr ausreichend, egal wie gut die Anwendungslogik ist.

2. Gemeinsame Datenbank, getrenntes Schema

Jeder Mandant bekommt sein eigenes Datenbankschema auf derselben Instanz. Kunde A hat tenant_42.orders, Kunde B hat tenant_99.orders. Die Datenbank kennt die Trennung – nicht nur die Anwendung.

Die Isolation ist besser: Ein falsch gesetzter JOIN landet nicht automatisch in fremden Daten. Einzelne Mandanten lassen sich gezielt sichern, exportieren oder löschen – was DSGVO-Löschanfragen deutlich handhabbarer macht.

Der versteckte Preis sind Migrationen. Bei zwanzig Kunden noch handhabbar. Bei zweihundert ist jede Schema-Änderung ein koordiniertes Deployment-Problem. Man braucht Tooling, das Schemas parallelisiert, Fehler pro Mandant protokolliert und Rollbacks einzeln ermöglicht. Teams unterschätzen diesen Aufwand regelmäßig – das Tooling kostet oft mehr als die eigentliche Migration.

3. Eigene Datenbank pro Mandant

Jeder Mandant bekommt eine eigene Datenbankinstanz. Maximale Isolation, maximale Betriebskomplexität.

Das klingt nach Enterprise-Overkill, ist es aber nicht immer. Wer wenige, zahlungskräftige Unternehmenskunden bedient, die eigene Compliance-Zertifizierungen verlangen, kommt an dieser Variante kaum vorbei. Datenbankmigrationen lassen sich gezielt pro Mandant einplanen. Performance-Limits lassen sich per Instanz setzen. Die Fehlersuche ist einfacher, weil Probleme strukturell isoliert sind.

Was es wirklich kostet:

Connection-Overhead: Hundert Datenbanken bedeuten hundert Connection-Pools – oder ein Connection-Proxy, der eigene Ausfallszenarien mitbringt.
Backup- und Monitoringkosten skalieren linear mit der Mandantenanzahl. Was bei fünf Kunden überschaubar ist, wird bei fünfzig zur Budgetfrage.
Infrastrukturautomation ist hier Pflicht, nicht Bonus. Neue Mandanten anlegen, Schema-Updates ausrollen, Incidents isolieren – das muss automatisiert sein, bevor es zehn Kunden gibt, nicht danach.
Feature-Rollouts werden zu Rollout-Kampagnen: Ein neues Feature muss hundertmal deployiert werden, nicht einmal, und jeder Fehler trifft genau einen Mandanten – den man dann einzeln reparieren muss.

Was die Wahl wirklich kostet – jenseits der Infrastruktur

Die Tenancy-Strategie beeinflusst nicht nur den Betrieb. Sie entscheidet maßgeblich mit, wie schnell ein Entwicklungsteam in den Folgejahren vorankommt.

Migrationsgeschwindigkeit

Shared-Schema-Projekte migrieren einmal, alle Mandanten gleichzeitig. Separate Schemas wachsen mit dem Kundenstamm in ihrer Migrationslast – jede neue Schema-Version muss für alle bestehenden Schemas eingespielt werden. Separate Datenbanken verwandeln eine einmalige Operation in einen fortlaufenden Rollout-Prozess mit eigenem Status-Tracking. Kein Ansatz ist inhärent besser – aber alle haben Folgekosten, die beim Start selten vollständig einkalkuliert werden.

Testbarkeit

Wer testet, dass kein Datenleck zwischen Mandanten besteht? In Shared-Schema-Projekten ist das eine eigene Testkategorie, die Teams regelmäßig vergessen. Der Test sieht auf den ersten Blick wie ein normaler Datenzugriffstest aus – ist aber einer, der beweisen muss, dass die Anwendungslogik unter keinen Umständen die tenant_id verliert oder falsch setzt. Das ist schwerer zu testen als es klingt, weil der Fehler oft erst dann sichtbar wird, wenn zwei Mandanten gleichzeitig aktiv sind.

Separate Datenbanken machen diesen Test einfacher, weil Isolation strukturell erzwungen ist. Dafür braucht man Testmandanten in der CI-Pipeline – nicht nur Testnutzer – und eine Infrastruktur, die das sauber abbilden kann, ohne bei jedem Build eine neue Datenbank zu provisionieren.

Debugging in der Produktion

In einer Shared-Schema-Umgebung betrifft ein Produktionsproblem oft alle Mandanten gleichzeitig. In isolierten Umgebungen lässt sich ein Problem auf einen Mandanten eingrenzen. Aber man bemerkt dabei oft erst, dass das übergreifende Monitoring fehlt: Hundert Datenbanken zu überwachen ist keine Aufgabe für ein Dashboard aus der Frühphase.

Wann welche Architektur sinnvoll ist

Eine ehrliche Einschätzung statt einer Rangliste:

Shared Schema eignet sich für frühe Produktphasen mit vielen kleinen Kunden, bei denen Datensensitivität gering ist und Betriebskosten niedrig gehalten werden müssen. Voraussetzung: Das Team versteht, dass Datenisolation auf Anwendungsebene aktiv erzwungen werden muss – und testet das konsequent.
Separate Schema ist ein sinnvoller Mittelweg, wenn Isolation gefragt ist, aber der Overhead separater Datenbankinstanzen unverhältnismäßig wäre. Der Preis ist das Migrations-Tooling, das von Anfang an konsequent mitgebaut werden muss.
Separate Datenbank macht Sinn bei hohen Compliance-Anforderungen, wenigen aber großen Unternehmenskunden oder wenn Kunden eigene SLAs mit physischer Datentrennung benötigen. In regulierten Branchen ist das oft keine Designentscheidung, sondern eine Voraussetzung für den Abschluss.

Was in der Praxis häufig passiert: Man beginnt mit Shared Schema wegen der Einfachheit, die ersten Unternehmenskunden verlangen Isolation, und man beginnt eine Migration unter laufendem Betrieb. Das ist machbar – aber es ist deutlich teurer, als wenn man das Ziel früh mitgedacht hätte.

Was Multi-Tenancy nicht löst

Das ist der Teil, den Architektur-Diagramme gerne weglassen.

Datenlecks passieren auf Anwendungsebene

Eine separate Datenbank schützt nicht vor einem Bug, der die tenant_id aus dem Session-Token falsch liest und dann die falsche Instanz öffnet. Isolation auf Infrastrukturebene reduziert den Blast Radius – sie ersetzt keine sorgfältige Implementierung der Zugriffslogik. Wer glaubt, durch die Wahl der Tenancy-Strategie das Thema Datensicherheit abhaken zu können, unterschätzt, wo Fehler tatsächlich entstehen.

DSGVO-Löschanfragen sind kein Datenbankproblem

Wer glaubt, mit einer separaten Datenbank pro Mandant sei „Löschen" trivial, unterschätzt, was alles Mandantendaten enthält: Logs, Analytics, Backups, Event-Streams, Caches, Volltextsuchindizes. Eine vollständige Löschprozedur muss all diese Stellen kennen und adressieren – und die meisten Systeme dokumentieren das nicht konsequent. Die DSGVO-konforme Löschung bleibt ein Prozessthema, keine Architekturfrage.

Performance-Isolation ist mehr als Datenbanktrennung

Wer einen Mandanten mit separater Datenbank betreibt, aber denselben Anwendungsserver und dieselben Worker-Queues teilt, hat das Noisy-Neighbor-Problem nicht gelöst, sondern nur auf eine andere Schicht verschoben. Echte Performance-Isolation erfordert Trennung auf allen Ebenen: Compute, Queues, Netzwerk. Wer das konsequent umsetzt, betreibt faktisch separate Deployments – mit allen damit verbundenen Kosten.

Die Entscheidung lässt sich nicht aufschieben

Anders als viele Architekturentscheidungen ist die Tenancy-Strategie schwer nachträglich zu ändern. Wer mit Shared Schema startet und später auf separate Datenbanken migrieren will, stellt fest: Die gesamte Datenzugriffsschicht muss umgebaut werden. Produktionsdaten müssen migriert, Kunden kurzzeitig in den Read-only-Modus versetzt oder ein langer Parallelbetrieb akzeptiert werden – bei dem beide Systeme gleichzeitig konsistent bleiben müssen.

Das heißt nicht, dass man vor dem ersten Kunden die perfekte Architektur haben muss. Es heißt, dass man die Entscheidung bewusst treffen sollte – mit einem klaren Bild davon, für welchen Kundenstamm man baut, welche Compliance-Anforderungen in zwei Jahren relevant werden und was ein späterer Umbau im laufenden Betrieb kostet.

Teams, die maßgeschneiderte Fachsoftware entwickeln, kennen diesen Moment: Der technische Ansprechpartner möchte eine Lösung, die in drei Jahren noch trägt. Die Fachabteilung will schnell live gehen. Beides ist verständlich. Die Aufgabe liegt darin, die Entscheidung mit ihren Folgekosten sichtbar zu machen – damit sie bewusst getroffen wird, und nicht irgendwann als technische Schuld wieder auf dem Tisch landet.