Multi-Tenant SaaS-Architekturmuster

Multi-Tenancy ist die Entscheidung, die Ihr gesamtes SaaS-Backend im Stillen prägt. Treffen Sie sie richtig, skalieren Sie reibungslos auf Tausende von Accounts. Treffen Sie sie falsch, schreiben Sie Ihre Datenschicht unter Last, mitten im Wachstum, vor den Augen Ihrer Kunden neu. Die gute Nachricht: Für die meisten Produkte ist die richtige Antwort einfacher, als das Internet vermuten lässt.

Die drei Modelle

Es gibt drei kanonische Ansätze zur Tenant-Isolierung – sie tauschen Isolation gegen Betriebskosten:

1. Row-Level (Shared Schema). Jede Tabelle hat eine tenant_id-Spalte, und jede Abfrage filtert darauf. Eine Datenbank, ein Schema, alle Tenants gemeinsam.
2. Schema-per-Tenant. Jeder Tenant erhält ein eigenes PostgreSQL-Schema innerhalb einer gemeinsamen Datenbank. Stärkere Isolierung, mehr Objekte zu verwalten.
3. Database-per-Tenant. Jeder Tenant erhält eine dedizierte Datenbank oder Instanz. Maximale Isolierung, maximaler Betriebsaufwand.

Warum Row-Level für die meisten SaaS die bessere Wahl ist

Für die große Mehrheit der B2B-SaaS-Produkte ist Row-Level Multi-Tenancy der richtige Standard. Sie ist am günstigsten im Betrieb, am einfachsten für Migrationen und skaliert weiter, als Gründer erwarten. Der Einwand lautet stets „aber die Isolierung" – und Postgres hat darauf eine überzeugende Antwort.

Row-Level Security (RLS) ermöglicht es der Datenbank selbst, durchzusetzen, dass eine Abfrage nur die Zeilen des eigenen Tenants sieht. Bei Supabase ist RLS das native Modell: Sie definieren eine Policy einmalig, und selbst eine fehlerhafte Abfrage kann keine Daten über Tenant-Grenzen hinweg leaken. Kombiniert mit einer tenant_id auf jeder Tabelle und einem Index, der damit beginnt, bedient dieses Muster komfortabel große Kundenstämme.

Ein Hinweis aus harter Erfahrung: Schreiben Sie RLS-Policies so, dass Hilfsfunktionen einmal pro Abfrage ausgeführt werden, nicht einmal pro Zeile. Eine Policy, die für jede Zeile eine Nachschlagetabelle erneut auswertet, macht schnelle Endpunkte mit wachsenden Tabellen still und leise langsam. Kapseln Sie die Prüfung so, dass der Planner sie als Init-Plan ausführt.

Wann stärkere Isolierung sinnvoll ist

Eskalieren Sie gezielt, nicht reflexartig:

• Regulatorische oder vertragliche Isolierung – ein Kunde verlangt, dass seine Daten in einer physisch getrennten Datenbank liegen.
• Noisy-Neighbor-Risiko – die Last eines einzelnen Großkunden beeinträchtigt alle anderen.
• Tenant-spezifische Anpassungen – Schemas weichen tatsächlich voneinander ab, nicht nur die Daten.

Auch dann funktioniert ein hybrider Ansatz gut: Die meisten Tenants bleiben auf Row-Level, nur Ihre größten oder sensibelsten Accounts werden auf dedizierte Datenbanken umgezogen.

Das Modell von Anfang an einplanen

Was auch immer Sie wählen – bauen Sie es frühzeitig ein:

• Fügen Sie tenant_id jeder Domänentabelle hinzu und beginnen Sie Ihre zusammengesetzten Indizes damit.
• Vertrauen Sie dem Client nie hinsichtlich des Tenants – leiten Sie ihn aus der authentifizierten Session ab.
• Erzwingen Sie Isolierung auf Datenbankebene, nicht nur auf Applikationsebene, damit eine vergessene WHERE-Klausel keine Daten leaken kann.
• Machen Sie das Tenant-Provisioning zu einem einzigen, getesteten Code-Pfad.

Der Fehler, der wirklich schmerzt, ist nicht die Wahl des „falschen" Modells – sondern Tenancy implizit zu lassen und Isolierungslogik über die gesamte Codebasis zu verstreuen. Zentralisieren Sie sie, erzwingen Sie sie in der Datenbank, und Sie behalten die Freiheit, sich weiterzuentwickeln.

Wenn Sie ein Multi-Tenant-Backend entwerfen und einen Partner suchen, der RLS-basierte PostgreSQL-Systeme in der Praxis skaliert hat, sprechen Sie uns an.