5 Anzeichen, dass Ihr SaaS-Produkt echte Multi-Tenant-Architektur braucht

Die meisten SaaS-Produkte starten mit einem Datenmodell, das technisch mehrere Kunden unterstützt, aber nicht dafür entworfen wurde: eine einzelne gemeinsame Datenbank mit einer nachträglich angefügten customer_id-Spalte. Das funktioniert gut, bis es das nicht mehr tut, und dieser Moment tritt meist zum denkbar ungünstigsten Zeitpunkt ein: mitten in einem Enterprise-Vertriebszyklus.

Das erste Anzeichen ist ein Interessent, der während der Einkaufsprüfung nach Garantien zur Datenisolation fragt. Das zweite ist eine Entwicklerin oder ein Entwickler, die oder der ein Einzelskript schreiben muss, um Daten zu korrigieren, die über Mandantengrenzen hinweg ausgetreten sind. Das dritte ist eine Abfrageleistung, die unvorhersehbar sinkt, während das Datenvolumen Ihres größten Kunden wächst und andere auf denselben Tabellen zu beeinträchtigen beginnt.

Das vierte Anzeichen ist der Bedarf an kundenspezifischer Konfiguration, Feature-Flags, benutzerdefinierten Feldern und unterschiedlichen Aufbewahrungsrichtlinien, verbunden mit der Erkenntnis, dass das aktuelle Schema dafür keinen sauberen Platz bietet. Das fünfte ist ein Kunde, der nach einer dedizierten Umgebung oder bestimmten Compliance-Garantien fragt, die Ihre Architektur nicht sauber liefern kann.

Sicherheit auf Zeilenebene, durchgesetzt in der Datenbankschicht statt nur im Anwendungscode, schließt die Isolationslücke tatsächlich. Eine anwendungsseitige Konvention wie „immer nach tenant_id filtern" funktioniert, bis irgendwo eine Abfrage das vergisst, und genau dieser eine Ausrutscher ist der Vorfall, der in einer Sicherheitsprüfung landet. Row-Level-Security-Policies in Postgres (oder das Äquivalent in Ihrer Datenbank) machen die Isolationsgrenze zu etwas, das die Datenbank durchsetzt, selbst wenn der Anwendungscode einen Fehler enthält.

Isolation zu testen muss angriffsorientiert sein, nicht nur funktional. Es reicht nicht zu prüfen, dass Mandant A die Daten von Mandant A sieht; es braucht Tests, die aktiv versuchen, Mandant A die Daten von Mandant B über jeden Codepfad sehen zu lassen, einschließlich Hintergrundjobs, Caching-Schichten und Suchindizes, genau dort, wo sich Isolationsfehler tatsächlich verstecken.

Die Migration selbst ist eher ein Sequenzierungs- als ein Engineering-Problem. Wir beginnen typischerweise mit den risikoreichsten Tabellen (denen, die bereits Leistungs- oder Leck-Symptome zeigen), fügen mandantenbewusste Indizierung und Row-Level-Security-Policies hinter einem Feature-Flag hinzu, validieren gegen Produktionstraffic im Schattenmodus und stellen dann Tabelle für Tabelle um, statt in einem einzigen Release.

Keines dieser Anzeichen bedeutet einen kompletten Neubau. Echte Multi-Tenant-Architektur ist meist eine schrittweise Migration: Sicherheit auf Zeilenebene, mandantenbewusste Indizierung und eine klare Isolationsgrenze, umgesetzt in Phasen hinter dem Produkt, das Ihre Kunden bereits nutzen. Teuer wird es nur in der Version, die unter Druck, während eines Abschlusses, statt im Vorfeld umgesetzt wird.