Die Wahl einer Multi-Tenancy-Architektur ist eine der folgenreichsten Entscheidungen im SaaS-Plattformdesign. Sie beeinflusst die Kostenstruktur, die Datenisolierung, die Leistungsmerkmale und die operative Komplexität für die gesamte Lebensdauer des Produkts. Die drei vorherrschenden Muster sind gemeinsame Datenbank mit Tenant-ID-Unterscheidung, Schema pro Tenant innerhalb eines gemeinsamen Datenbankservers und vollständig isolierte Datenbank pro Tenant. Jedes Muster belegt einen anderen Punkt im Spektrum zwischen operativer Effizienz und Tenant-Isolierung. Wir haben SaaS-Produktionsplattformen mit allen drei Mustern gebaut und können konkrete Empfehlungen geben, wie Sie das Muster an den Geschäftskontext anpassen.
Das Muster der gemeinsamen Datenbank speichert alle Tenant-Daten in gemeinsamen Tabellen, die durch eine Tenant-ID-Spalte unterschieden werden. Dies ist der kosteneffizienteste Ansatz, da die Infrastruktur mit dem Gesamtdatenvolumen statt mit der Tenant-Anzahl skaliert. Das Hinzufügen eines neuen Tenants ist sofort möglich und erfordert keine Bereitstellung. Dieses Muster erfordert jedoch rigorose Disziplin beim Abfrage-Design: Jede Abfrage muss den Tenant-ID-Filter enthalten, und ein vergessener Filter bedeutet ein katastrophales Datenleck. Wir minimieren dieses Risiko mit Row-Level-Security-Richtlinien auf Datenbankebene und einer obligatorischen Tenant-Kontext-Middleware, die den Filter automatisch einfügt. Performance-Isolierung ist die andere Herausforderung, da ein einzelner Tenant mit schweren Abfragen ohne sorgfältige Ressourcenverwaltung alle anderen beeinflussen kann.
Schema pro Tenant bietet eine stärkere logische Isolierung bei gemeinsamer Nutzung des zugrunde liegenden Datenbankservers. Jeder Tenant erhält sein eigenes Schema mit identischen Tabellenstrukturen, und die Anwendung wechselt das Schema basierend auf dem authentifizierten Tenant-Kontext. Dieses Muster vereinfacht Compliance-Gespräche, da Sie klare Datengrenzen nachweisen können, und mandantenspezifische Schemamigrationen werden für Enterprise-Anpassungen möglich. Die Betriebskosten wachsen linear mit der Tenant-Anzahl, da jedes Schema eine unabhängige Migrationsverwaltung erfordert. Wir haben festgestellt, dass dieses Muster gut für B2B-SaaS-Produkte mit Dutzenden bis Hunderten von Tenants funktioniert, bei denen die Anforderungen an die Datenisolierung moderat sind und eine gewisse mandantenspezifische Anpassung erwartet wird.
Datenbank pro Tenant bietet die stärksten Isolierungsgarantien. Jeder Tenant hat eine vollständig unabhängige Datenbankinstanz, potenziell auf dedizierter Hardware. Dieses Muster ist notwendig, wenn Tenants regulatorische Anforderungen an den Datenspeicherort haben, wenn die Performance-Isolierung absolut sein muss oder wenn Tenants die Möglichkeit benötigen, eigene Verschlüsselungsschlüssel zu verwenden. Der Kompromiss ist ein erheblicher operativer Overhead: Bereitstellung, Überwachung, Backup und Migration müssen für jede Tenant-Instanz automatisiert werden. Die Kosten skalieren direkt mit der Tenant-Anzahl unabhängig von der Nutzung. Wir empfehlen dieses Muster für Enterprise-SaaS-Produkte mit weniger als hundert hochwertigen Tenants, bei denen die Isolierungsanforderungen die Infrastrukturinvestition rechtfertigen.