Multitenancy in SaaS: Silo, Pool oder Bridge — und der Weg dazwischen

Die teuerste Entscheidung vor dem ersten Kunden

In einer SaaS-Plattform ist das Tenancy-Modell der Punkt, an dem sich Unit Economics, Sicherheitsniveau und Entwicklungsgeschwindigkeit kreuzen. Es bestimmt, was Sie jeder neue Kunde kostet, wie weit sich ein Vorfall ausbreitet, was Sie einem Auditor glaubwürdig zusagen können und wie schmerzhaft jede künftige Migration wird. Teams verbringen routinemäßig Wochen mit der Wahl des Frontend-Frameworks und einen Nachmittag mit dem Tenancy-Modell. Das Verhältnis gehört umgekehrt: Frameworks lassen sich austauschen, Tenancy-Modelle verfestigen sich.

Drei kanonische Modelle decken das Feld ab — Silo, Pool und Bridge — und keines ist schlicht das beste. Jedes ist eine Position auf einem Spektrum, das Isolation gegen Betriebskosten tauscht. Die nützliche Frage lautet nicht, welches Modell richtig ist, sondern welche Kompromisse Ihr Geschäft in seiner aktuellen Phase tragen kann — und wie teuer ein späterer Kurswechsel wird.

Silo, Pool, Bridge — die tatsächlichen Trade-offs

Die drei Modelle unterscheiden sich darin, was sie teilen und was sie dedizieren — und ihre Fehlermodi folgen direkt aus dieser Wahl.

• Silo — jeder Mandant erhält dedizierte Ressourcen, in der Regel eine Datenbank, oft auch Compute. Stärkste Isolation und der einfachste Compliance-Nachweis, aber eine harte Kostenuntergrenze pro Mandant und ein Flottenproblem: Zweihundert Mandanten bedeuten zweihundert Datenbanken, die migriert, gesichert, gepatcht und überwacht werden müssen.
• Pool — alle Mandanten teilen sich die Infrastruktur, getrennt durch eine tenant_id. Die Grenzkosten pro Mandant gehen gegen null und der Betrieb bleibt einheitlich, doch die Isolation wird zur Aufgabe der Anwendung, und eine einzige schlechte Query kann alle zugleich ausbremsen.
• Bridge — gemeinsames Compute über getrennten Daten (Schema oder Datenbank pro Mandant) oder eine gestufte Flotte: gepoolte Infrastruktur für den Standardtarif, dedizierte Silos für regulierte oder Enterprise-Mandanten.

Unser Standard für B2B-Produkte ist ein Pool-Modell hinter einer strikten Tenancy-Abstraktion, mit Silo als bepreister Premium-Stufe — nicht als Reflex. Dedizierte Infrastruktur, die niemand bezahlt, ist keine Architektur, sondern eine Subvention.

Isolation ist mehrschichtige Verteidigung, keine WHERE-Klausel

Eine tenant_id-Spalte plus Entwicklerdisziplin ist keine Isolationsstrategie; sie ist einen vergessenen Filter von einer meldepflichtigen Datenpanne entfernt. Isolation muss auch dann halten, wenn ein Entwickler einen Fehler macht — also gehört sie auf mehrere unabhängige Ebenen.

• Lösen Sie den Mandantenkontext genau einmal am Rand auf — aus Subdomain, Token oder Header — und reichen Sie ihn durch jede Anfrage, jeden Job und jedes Event weiter; nichts weiter unten darf ihn selbst neu ableiten.
• Machen Sie mandantenübergreifende Queries konstruktiv unmöglich: Repositories oder Query-Builder, die den Mandantenkontext per Konstruktion verlangen, nicht per Konvention.
• Aktivieren Sie Row-Level Security in der Datenbank als letzte Sicherung: Ein vergessener Filter lässt die Query scheitern, statt einen Datenbestand offenzulegen.
• Verschlüsseln Sie regulierte Felder mit Schlüsseln pro Mandant — Offboarding und Löschbegehren werden so zu Schlüsseloperationen statt zu Tabellenscans.
• Pflegen Sie eine automatisierte Testsuite für mandantenübergreifende Zugriffe und behandeln Sie jeden Fehlschlag darin als Sicherheitsvorfall, nicht als Bug-Ticket.

Noisy Neighbors sind ein Fairness-Problem, kein Kapazitätsproblem

Im Pool-Modell ist die Kapazität geteilt, und ohne explizite Fairness-Regeln bestimmt der größte Mandant die Latenz aller anderen. Mehr Hardware hebt nur die Decke eines unfairen Schedulers. Zuerst kommt die Attribution: Messen Sie den Verbrauch pro Mandant vom ersten Tag an, denn eine Handvoll Mandanten wird den Großteil der Last erzeugen — und was Sie nicht zuordnen, können Sie nicht steuern.

• Setzen Sie Rate Limits und Kontingente pro Mandant auf API-Ebene durch und preisen Sie sie in die Tarife ein, damit Limits ein kommerzieller Hebel sind, keine Entschuldigung.
• Begrenzen Sie die Parallelität pro Mandant in Hintergrund-Queues — der Massenimport des einen darf die Webhooks des anderen niemals verzögern.
• Setzen Sie Statement-Timeouts und leiten Sie analytische Queries auf Replikate; der transaktionale Pfad ist kein Ort für Reporting.
• Auf Flottenebene begrenzen zellbasierte Architektur und Shuffle Sharding den Wirkungsradius von Überlast ebenso wie von fehlerhaften Deployments.

Observability, die das Wort Mandant kennt

Die erste Frage in jedem SaaS-Vorfall lautet: Wer ist betroffen? Kann Ihre Telemetrie das nicht in Sekunden beantworten, haben Sie Dashboards, keine Observability. Machen Sie die Mandantenidentität zu einer zentralen Dimension in Logs, Traces und Metriken — mit bewusst gesteuerter Kardinalität: volle Auflösung in Logs und Traces, Top-N plus aggregierte Reihen in den Metriken.

Definieren Sie SLOs pro Mandant mindestens für Ihre oberste Stufe und messen Sie den Verbrauch kontinuierlich. Dieselben Daten beantworten Support-Fragen in Minuten, stützen nutzungsbasierte Preismodelle und zeigen die Kunden, die Sie stillschweigend mit Verlust bedienen.

Planen Sie die Migration, bevor Sie sie brauchen

Mit welchem Modell Sie auch starten — irgendwann muss ein Mandant umziehen: Ein Enterprise-Vertrag verlangt ein Silo, oder eine Silo-Flotte wird im Betrieb zu teuer. Der Migrationspfad ist Teil der Architektur, kein nachträglicher Gedanke.

• Behalten Sie die tenant_id auf jeder Zeile, auch in Silo-Datenbanken — Konsolidierung ohne sie ist Archäologie.
• Halten Sie die Schemata über alle Silos identisch; Schema-Drift verwandelt eine Migration unbemerkt in eine Neuentwicklung.
• Routen Sie Mandanten über eine stabile Abstraktion, die jeden Mandanten seinem Datenstandort zuordnet — so kann sich dieser Standort ändern, ohne die Anwendung anzufassen.
• Proben Sie den Umzug: mandantenbezogener Export, Umschaltung per Replikation, ein kurzes Dual-Write-Fenster und ein verifizierter Rollback.

Das Modell, mit dem Sie starten, wird nicht das Modell sein, mit dem Sie enden. Aufgabe der Architektur ist es, aus diesem Wechsel ein geplantes Projekt zu machen — statt eines unternehmensweiten Notfalls.