Multi-Tenancy in der Praxis

Multi-Tenancy ist die Eigenschaft einer SaaS-Plattform, mehrere Kundenorganisationen gleichzeitig zu bedienen — getrennt voneinander, aber auf derselben Infrastruktur. Was technisch klingt, ist tatsächlich eine der weitreichendsten Architektur-Entscheidungen einer SaaS-Plattform: Sie entscheidet darüber, wie die Plattform skaliert, wie Daten getrennt werden, wie Updates ausgerollt werden und wie hoch die Betriebskosten pro Kunde sind.

Multi-Tenancy lässt sich technisch auf mehrere Arten umsetzen — und die Wahl der falschen Strategie ist später nur mit großem Aufwand zu korrigieren.

In der Praxis stehen drei grundlegende Ansätze zur Wahl — jeder mit eigenen Konsequenzen:

Row-based passt, wenn...

• die Plattform viele kleinere Mandanten bedient.
• die Datenmengen pro Mandant überschaubar bleiben.
• Betriebskosten minimal sein müssen.
• die Mandanten-Trennung rein logisch ist und keine regulatorischen Vorgaben dagegen sprechen.

Schema-based passt, wenn...

• die Mandanten größer sind und individuelle Datenexporte gefragt sind.
• regulatorische Anforderungen eine stärkere Trennung verlangen.
• Performance-Optimierungen pro Mandant nötig sein können.
• die Anzahl der Mandanten im überschaubaren Rahmen (bis ein paar hundert) bleibt.

Database-based passt, wenn...

• die Kunden Banken, Versicherungen, Healthcare oder vergleichbar regulierte Branchen sind.
• Compliance (DSGVO, branchenspezifische Vorgaben) eine vollständige Trennung erfordert.
• jeder Mandant ein klassisches Großkundengeschäft mit eigenen SLAs ist.

Hybrid ist häufig die ehrliche Antwort, wenn die Plattform unterschiedliche Kundensegmente bedient. Komplexer im Betrieb, aber wirtschaftlich oft die beste Lösung.

Über die Strategie-Wahl hinaus gibt es Aspekte, die in jeder Multi-Tenancy-Implementierung kritisch sind:

• Sichere Datenisolation. Kein Mandant darf — durch geschickte URL-Manipulation, durch SQL-Injection oder durch fehlerhafte Berechtigungen — auf Daten anderer Mandanten zugreifen können.
• Tenant-Aware Code von Anfang an. Jede Datenbankabfrage, jeder Cache-Zugriff, jeder Hintergrund-Job berücksichtigt den Mandanten-Kontext. Sauber: zentraler Tenant-Resolver, der bei jedem Request den Kontext setzt.
• Konfiguration pro Mandant. Branding, Spracheinstellungen, aktivierte Funktionen, individuelle Workflows. Idealerweise so abgebildet, dass neue Konfigurationen ohne Code-Änderung möglich sind.
• Pro-Mandant-Limits. Wie viele Nutzer, wie viel Speicher, wie viele API-Aufrufe pro Tag? Limits müssen erzwungen werden, sonst übernimmt ein einziger Mandant die ganze Plattform.
• Tenant-Migration. Was passiert, wenn ein Mandant von Row-based zu Schema-based wechselt — oder die Plattform verlässt? Migrationspfade gehören ins Konzept.
• Reporting und Admin. Plattform-Betreiber brauchen einen Blick über alle Mandanten — für Abrechnung, Monitoring und Support.

Vier Punkte, an denen Multi-Tenancy-Implementierungen regelmäßig stolpern:

• Vergessene Tenant-Filter. Eine einzige Datenbankabfrage ohne tenant_id-Filter — und plötzlich sieht ein Kunde die Daten eines anderen. Disziplin durch Architektur: Tenant-Filter nicht manuell, sondern durch Middleware oder ORM-Layer erzwingen.
• Geteilte Caches ohne Tenant-Schlüssel. Caches, die nicht pro Mandant getrennt sind, können in Sekunden zu massivem Datenleck führen. Cache-Keys müssen den Tenant-Kontext enthalten.
• Hintergrund-Jobs ohne Kontext. Asynchrone Verarbeitung läuft oft außerhalb des HTTP-Request-Kontexts. Der Mandant muss explizit mit dem Job übergeben werden — sonst greift der Job auf falsche Daten zu.
• Statistik- und Reporting-Lücken. Übergreifende Reports übersehen oft Mandanten-Filter — und zeigen Daten, die der jeweilige Nutzer nicht sehen darf.

Ein bewährter Ansatz für die meisten mittelständischen SaaS-Projekte:

1. Strategie früh festlegen. Im Konzept, nicht in der dritten Iteration. Row-, Schema- oder Database-based — diese Entscheidung trägt durch das ganze Projekt.
2. Tenant-Kontext als Architektur-Grundlage. Jede Abfrage, jeder Cache, jeder Job läuft in einem klar definierten Mandanten-Kontext — durchgesetzt durch zentrale Middleware, nicht durch Disziplin im Einzelfall.
3. Sicherheits-Tests von Anfang an. Testfälle, die explizit prüfen, ob Mandant A Daten von Mandant B sehen kann. Diese Tests laufen bei jedem Release.
4. Mit Row-based starten — wenn die Anforderungen passen. Einfacher Betrieb, geringere Kosten, ausreichend für die meisten SaaS-Anwendungen im B2B-Mittelstand.
5. Migrationspfade einplanen. Wenn die Plattform wächst und einzelne Großkunden eigene Datenbanken brauchen, sollte die Architektur das ohne Komplettumbau ermöglichen.