Mandantenfähige SaaS-Architektur: Was CTOs wissen müssen

Sie entwickeln ein SaaS-Produkt. Mehrere Kunden werden es nutzen. Jeder Kunde erwartet, dass seine Daten vertraulich bleiben, dass seine Konfigurationen getrennt bleiben und dass sich sein Erlebnis wie eine eigene Plattform anfühlt. Die Frage ist nicht, ob Sie Mandantenfähigkeit benötigen. Es kommt darauf an, welches Modell Sie wählen.

Diese Entscheidung prägt Ihr Datenbankschema, Ihre Bereitstellungspipeline, Ihre Compliance-Story und Ihre Kostenstruktur über Jahre hinweg. Wenn Sie etwas falsch machen, verbringen Sie sechs Monate damit, auf ein anderes Modell zu migrieren, während Ihre Roadmap ins Stocken gerät.

Es gibt drei Modelle, die eine Überlegung wert sind. Bei jedem geht es auf unterschiedliche Weise um Kosten, Isolation und betriebliche Komplexität.

Die drei Multi-Tenant-Architekturmodelle

1. Datenbank pro Mandant

Jeder Mieter erhält seine eigene Datenbank. Die Anwendungsschicht leitet Abfragen basierend auf einer Mandantenkennung, die normalerweise aus der Subdomäne, dem API-Schlüssel oder dem JWT-Anspruch aufgelöst wird, an die richtige Datenbank weiter.

Dies ist das stärkste Isolationsmodell. Die Daten von Mieter A befinden sich in einer von den Daten von Mieter B getrennten Datenbank. Es besteht keine Möglichkeit, dass ein Abfragefehler Zeilen über Mandanten hinweg verliert, da die Zeilen in unterschiedlichen Datenbanken mit unterschiedlichen Verbindungen vorhanden sind.

Vorteile:

• Compliance-freundlich. Prüfer hören gerne: „Jeder Kunde hat seine eigene Datenbank.“ SOC 2, HIPAA und Datenresidenzanforderungen werden zu unkomplizierten Gesprächen.
• Sicherung und Wiederherstellung pro Mandant. Wenn ein Mandant Sie auffordert, auf den gestrigen Zustand zurückzusetzen, stellen Sie eine Datenbank wieder her. Keine chirurgische Extraktion von gemeinsam genutzten Tischen.
• Kein Risiko durch laute Nachbarn. Ein Mandant, der teure Analyseabfragen ausführt, kann die Leistung anderer Mandanten nicht beeinträchtigen.
• Skalierung pro Mandant. Sie können hochwertige Mandanten auf größeren Datenbankinstanzen platzieren.

Nachteile:

• Teuer. Für jede Datenbank gelten Grundkosten: Rechenleistung, Speicherung, Sicherungen, Überwachung. Bei 10 Mietern ist das überschaubar. Bei 500 handelt es sich um eine Werbebuchung, die Ihrem CFO Unbehagen bereitet.
• Migrationshölle. Schemaänderungen müssen in Hunderten von Datenbanken ausgeführt werden. Sie benötigen Tools, um Migrationen zu orchestrieren, zu verfolgen, welche Datenbanken auf dem neuesten Stand sind, und um Fehler während eines Rollouts zu beheben.
• Das Verbindungspooling wird kompliziert. Ihr Anwendungsserver benötigt Verbindungspools zu Hunderten von Datenbanken. Verbindungsbeschränkungen werden zu einer Einschränkung, bevor CPU oder Speicher dies tun.
• Mandantenübergreifende Abfragen sind schmerzhaft. Aggregierte Berichte, plattformweite Analysen oder Admin-Dashboards, die mandantenübergreifende Daten anzeigen, erfordern Verbundabfragen oder eine separate Analysepipeline.

Am besten für:Fintech-, Gesundheitswesen- und Unternehmens-SaaS mit strengen Anforderungen an die Datenresidenz. Wenn in Ihrem Vertrag steht: „Kundendaten müssen sich in einer bestimmten AWS-Region befinden“ oder „Daten müssen innerhalb von 24 Stunden nach Vertragsbeendigung löschbar sein“, macht die Datenbank pro Mandant beides problemlos erreichbar.

2. Gemeinsame Datenbank, Schematrennung

Eine Datenbank, aber jeder Mandant erhält sein eigenes Schema (Namespace). In PostgreSQL bedeutet dies, dass jeder Mandant über einen separaten Tabellensatz unter seinem eigenen Schemanamen verfügt: tenant_abc.users, tenant_xyz.users. Die Anwendung legt den search_path für jede Verbindung fest, um Abfragen an das richtige Schema weiterzuleiten.

Das ist der Mittelweg. Sie erhalten eine bessere Isolation als gemeinsam genutzte Tabellen und das bei geringeren Kosten als bei separaten Datenbanken.

Vorteile:

• Günstiger als Datenbank pro Mandant. Eine Datenbankinstanz, ein Verbindungspool, ein Überwachungsstapel.
• Anständige Isolation. Schemas stellen eine Namespace-Grenze bereit. Eine falsch konfigurierte Abfrage in einem Schema kann nicht auf die Tabellen eines anderen Schemas zugreifen (vorausgesetzt, Sie haben search_path richtig festgelegt).
• Eine Sicherung pro Mandant ist über pg_dump --schema möglich.
• Migrationen sind einfacher als Datenbank-pro-Mandanten-Migrationen. Sie führen die Migration einmal pro Schema durch, aber alle Schemas befinden sich in derselben Datenbank, sodass die Tools einfacher sind.

Nachteile:

• Schemadrift. Wenn Migrationen bei einigen Schemas fehlschlagen, bei anderen jedoch erfolgreich sind, führt dies letztendlich dazu, dass Mandanten unterschiedliche Versionen Ihres Schemas ausführen. Das zu debuggen ist miserabel.
• PostgreSQL kann mit Tausenden von Schemata nicht gut umgehen. Ab 5.000–10.000 Schemata kommt es zu Leistungseinbußen bei pg_catalog-Suchvorgängen, langsameren pg_dump-Zeiten und Autovacuum-Konflikten.
• Gleiches Noisy-Neighbor-Risiko wie bei einer gemeinsam genutzten Datenbank. Die teure Abfrage eines Mandanten konkurriert immer noch um die gleiche CPU und E/A.
• Die Werkzeugunterstützung ist inkonsistent. ORMs und Migrationsframeworks bieten unterschiedliche Unterstützungsstufen für Schema-pro-Mandanten-Muster.

Am besten für:Mittelständisches SaaS mit 50–5.000 Mandanten, bei dem Sie eine bessere Isolierung als Sicherheit auf Zeilenebene benötigen, sich aber die Kosten für separate Datenbanken nicht rechtfertigen können.

3. Alles mit Sicherheit auf Zeilenebene geteilt

Alle Mieter teilen sich die gleichen Tische. Eine tenant_id-Spalte in jeder Tabelle gibt an, welcher Mandant jede Zeile besitzt. RLS-Richtlinien (Row-Level Security) in PostgreSQL erzwingen, dass Abfragen nur Zeilen sehen können, die zum aktuellen Mandanten gehören.

Dies ist das gängigste Modell für B2B-SaaS-Produkte, die nicht an regulierte Unternehmen verkauft werden.

Vorteile:

• Günstigste Infrastrukturkosten. Eine Datenbank, ein Tabellensatz, ein Verbindungspool. Das Hinzufügen eines Mieters kostet keine zusätzliche Infrastruktur.
• Einfachste Migrationen. Ein Schema, ein Migrationslauf. Sie orchestrieren nichts über mehrere Datenbanken oder Schemata hinweg.
• Ein Codebasispfad. Keine bedingte Logik für „mit welcher Datenbank spreche ich“ oder „welches Schema soll ich verwenden“. Die Spalte tenant_id ist Teil des Schemas und RLS übernimmt den Rest.
• Mandantenübergreifende Analysen sind trivial. Admin-Dashboards und plattformweite Berichte fragen dieselben Tabellen mit erhöhten Berechtigungen ab.

Nachteile:

• Abfragefehler können zu Datenlecks führen. Wenn ein Entwickler eine Abfrage schreibt, die RLS umgeht (unter Verwendung einer Superuser-Verbindung oder durch Vergessen, die Sitzungsvariable festzulegen), kommt es zu Mandantendatenlecks. Hierbei handelt es sich um ein Risiko auf Codeebene und nicht um eine Garantie auf Infrastrukturebene.
• Compliance-Gespräche sind schwieriger. „Alle Kundendaten befinden sich in denselben Tabellen, getrennt durch eine Spalte“ ist für Unternehmenssicherheitsteams schwieriger zu verkaufen als „Jeder Kunde hat seine eigene Datenbank“.
• Das Risiko lauter Nachbarn ist hier am höchsten. Ein Mandant, der 10 Millionen Zeilen importiert, sperrt Tabellen, die sich auf alle Mandanten auswirken.
• Die Sicherung und Wiederherstellung pro Mandant erfordert eine chirurgische Entfernung. Sie können keinen einzelnen Mandanten wiederherstellen, ohne benutzerdefinierte Tools zu schreiben.

Am besten für:B2B-SaaS unterhalb der Unternehmensebene. Produkte mit Hunderten oder Tausenden von Mietern, bei denen die Infrastrukturkosten wichtiger sind als Compliance-Zertifizierungen.

Vergleichstabelle

Wie wir DropTaxi auf der Mehrmandantenfähigkeit einer gemeinsam genutzten Datenbank aufgebaut haben

Als wir gebaut habenDropTaxi, einem Multi-Tenant-Taxibuchungs-SaaS für indische Betreiber, haben wir uns für das gemeinsame Datenbankmodell mit tenant_id-Spalten entschieden.

Die Begründung war einfach. Taxiunternehmen sind Kleinunternehmen. Sie haben keine Compliance-Anforderungen, die eine Isolierung auf Datenbankebene erfordern. Die Mieterzahl musste ohne Infrastrukturkosten pro Mieter von 5 auf über 500 skaliert werden. Und das Onboarding musste sofort erfolgen: Anmelden, Branding konfigurieren, Domain angeben, live gehen. Keine Bereitstellung, keine Bereitstellung, kein Warten.

So sieht die Architektur in der Praxis aus:

Mandanten-Onboarding ohne Bereitstellung.Das Hinzufügen eines neuen Mieters bedeutet das Einfügen einer Zeile in die Tabelle tenants mit Markennamen, Farben, Logo-URL, Domäne, Tarifen und Telegram-Bot-Token. Es wird keine CI-Pipeline ausgeführt. Kein Container-Neustart. Die nächste Anfrage an diese Domäne löst den neuen Mandanten auf und rendert seine gebrandete Website.

Gebrandete Subdomains über Middleware.Jede eingehende HTTP-Anfrage trifft auf eine Hono-Middleware-Schicht, die den Header Host liest. Die Middleware fragt die Datenbank ab (über Drizzle ORM auf Turso), um den Mandanten zu finden, der zu dieser Domäne passt. Wenn eine Übereinstimmung gefunden wird, wird die vollständige Konfiguration des Mandanten in den Anforderungskontext geladen. Ist dies nicht der Fall, erhält die Anfrage eine 404. Die Astro SSR-Schicht rendert dann Seiten unter Verwendung des Brandings des Mieters, sodass Besucher eine eigenständige Taxibuchungsseite und keine generische Plattform sehen.

Einzelne Bereitstellung für alle Mandanten.Eine Fly.io-Maschine betreibt die gesamte Plattform. Eine Datenbank. Eine Codebasis. Die einzigen Kosten pro Mandant sind die DNS-Konfiguration und die Zeilen in der Datenbank, in denen ihre Einstellungen gespeichert sind.

Dieses Modell funktioniert, weil das Produkt keine regulierten Branchen bedient, die Datensensibilität gering ist (Buchungsdetails, keine Finanzunterlagen) und das Hauptproblem bei der Skalierung die Anzahl der Mieter und nicht das Datenvolumen pro Mieter ist.

Praktische Muster für mandantenfähige Systeme

Unabhängig davon, welches Modell Sie wählen, zeigen sich diese Muster in Produktionssystemen mit mehreren Mandanten.

Middleware zur Mieterauflösung

Die Mandantenauflösung sollte einmal am Rande Ihrer Anforderungspipeline erfolgen und der aufgelöste Mandant sollte sich über den gesamten Anforderungslebenszyklus verbreiten. Gängige Lösungsstrategien:

• Subdomain:acme.yourapp.com wird in den Mandanten acme aufgelöst. Analysieren Sie den Header Host.
• Benutzerdefinierte Domäne:app.acme.com wird über eine Domänen-Nachschlagetabelle einem Mandanten zugeordnet.
• Pfadpräfix:yourapp.com/acme/dashboard extrahiert den Mandanten aus der URL. In der Produktion weniger verbreitet, aber während der Entwicklung nützlich.
• JWT/API-Schlüssel:Bei API-First-Produkten befindet sich die Mandantenkennung im Authentifizierungstoken. Die Middleware validiert das Token und extrahiert den Mieteranspruch.

Speichern Sie den aufgelösten Mandanten im anforderungsbezogenen Kontext (Honos c.set(), Expresss req.tenant oder eine Thread-lokale Variable in Go). Es sollte kein Downstream-Code erforderlich sein, den Mandanten neu aufzulösen.

Verbindungspooling

Im Datenbank-pro-Mandanten-Modell wird das Verbindungspooling zum ersten Engpass, auf den Sie stoßen. Jede Mandantendatenbank benötigt einen eigenen Pool, und Ihr Anwendungsserver verfügt über eine begrenzte Anzahl von Verbindungen, die er offen halten kann.

Lösungen, die in der Produktion funktionieren:

• PgBouncer pro Datenbankinstanzmit Pooling auf Transaktionsebene. Dadurch werden viele Anwendungsverbindungen über eine kleinere Anzahl von Datenbankverbindungen gemultiplext.
• Lazy-Pool-Initialisierung.Erstellen Sie keine Verbindungspools für Mandanten, die in der letzten Stunde keine Anfrage erhalten haben. Starten Sie Pools bei Bedarf und entfernen Sie inaktive Pools mit einer TTL.
• Verwaltete Pooling-Dienstewie der Verbindungspooler von Supabase oder der serverlose Treiber von Neon, die die Poolverwaltung außerhalb Ihres Anwendungsprozesses übernehmen.

Bei Modellen mit gemeinsam genutzter Datenbank funktioniert ein einzelner Verbindungspool einwandfrei. Der Mandantenkontext wird bei jedem Verbindungsauschecken auf Sitzungsebene festgelegt (SET app.current_tenant für RLS, SET search_path für Schematrennung).

Mandantenbezogenes Caching

Ihre Cache-Schlüssel benötigen ein Mandantenpräfix. Wenn Sie einen „Dashboard-Daten“-Schlüssel zwischenspeichern, ohne ihn einem Mandanten zuzuordnen, stellen Sie Mandant B die Dashboard-Daten von Mandant A zur Verfügung. Das klingt offensichtlich, ist aber der häufigste Fehler bei der Mehrmandantenfähigkeit in der Produktion.

Verwenden Sie ein Schlüsselformat wie tenant:{tenant_id}:resource:{resource_type}:{resource_id}. Wenn Sie Redis verwenden, sollten Sie für kleinere Bereitstellungen separate Redis-Datenbanken pro Mandant (standardmäßig sind 0–15 verfügbar) oder für größere Bereitstellungen Schlüsselpräfixe in Betracht ziehen.

Isolierung von Hintergrundjobs

Hintergrundjobs (E-Mail-Versand, Berichtserstellung, Datenimporte) erfordern die Weitergabe des Mandantenkontexts von der Enqueue-Site an den Worker. Wenn Sie einen Job in die Warteschlange stellen, fügen Sie den tenant_id in die Job-Nutzlast ein. Der Worker sollte denselben Mandantenkontext einrichten, den Ihre HTTP-Middleware bereitstellt, bevor er den Job verarbeitet.

Verwenden Sie zum Schutz vor lauten Nachbarn in Auftragswarteschlangen separate Warteschlangen oder Warteschlangenprioritäten pro Mandant. Ein Mieter, der 100.000 Datensätze importiert, sollte die Willkommens-E-Mails eines anderen Mieters nicht blockieren. BullMQ, Sidekiq und Celery unterstützen alle benannte Warteschlangen, mit denen Sie Mieter mit hohem Volumen an dedizierte Mitarbeiter weiterleiten können.

Multiportal als Mandantenfähigkeitsvariante

Mandantenfähigkeit bedeutet nicht nur „gleiche App, verschiedene Kunden“. Es kann auch „gleiche Plattform, unterschiedliche Benutzerrollen mit separaten Portalen“ bedeuten. Als wir gebaut habenZestAMCBei , einer rollenbasierten Multiportalplattform, nutzte die Architektur dieselbe Datenbank und Codebasis, stellte jedoch unterschiedliche Schnittstellen für unterschiedliche Benutzertypen bereit: Administratoren, Manager und Außendienstmitarbeiter. Jedes Portal hatte sein eigenes Routing, seine eigenen Berechtigungen und seine eigene Benutzeroberfläche, aber alle basierten auf derselben Datenschicht mit Scoping auf Zeilenebene.

Dies ist ein nützliches Muster, wenn Ihre „Mandanten“ keine separaten Organisationen, sondern separate Rollen innerhalb einer Organisation sind. Die Multi-Tenant-Primitive (bereichsbezogener Datenzugriff, Middleware pro Rolle, Kontextweitergabe) bleiben gleich.

Entscheidungsrahmen: So wählen Sie Ihr Modell aus

Das richtige Modell hängt von drei Variablen ab: Compliance-Anforderungen, erwartete Mieterzahl und Infrastrukturbudget.

Beginnen Sie mit der Compliance.Wenn Ihre Kunden in regulierten Branchen tätig sind (Finanzen, Gesundheitswesen, Regierung) oder Ihre Verträge Datenresidenzklauseln enthalten, ist die Datenbank pro Mandant die sicherste Wahl. Die Kostenprämie ist ein Einzelposten in Unternehmensverträgen, für den Ihre Kunden voraussichtlich zahlen werden.

Berücksichtigen Sie die Anzahl der Mieter.Wenn Sie mit weniger als 100 Mandanten rechnen und jeder Mandant einen nennenswerten Umsatz generiert, ist die Datenbank pro Mandant sinnvoll. Zwischen 100 und 5.000 funktioniert die Schematrennung, wenn Sie PostgreSQL verwenden und in Migrationstools investieren können. Über 5.000 ist die gemeinsame Nutzung von Tabellen mit RLS die pragmatische Wahl. Die Infrastrukturökonomie der anderen Modelle bricht bei hohen Mieterzahlen zusammen.

Überprüfen Sie Ihr Budget.Wenn Sie sich in der Pre-Revenue- oder Seed-Phase befinden, können Sie mit gemeinsam genutzten Tabellen mit RLS schneller versenden und weniger ausgeben. Sie können später zu einem stärkeren Isolationsmodell migrieren, wenn Unternehmenskunden danach fragen (und dafür bezahlen). Bei den meisten SaaS-Produkten muss diese Migration nie durchgeführt werden, da die meisten SaaS-Produkte an KMUs verkauft werden, denen Funktionen und nicht Datenbankisolationsmodelle wichtig sind.

Betrachten Sie den Hybridansatz.Einige Produkte führen gemeinsam genutzte Tabellen für ihre Standardstufe und Datenbank pro Mandant für Unternehmenskunden aus. Dies stellt zwar eine höhere betriebliche Komplexität dar, ermöglicht Ihnen aber die Bedienung beider Märkte, ohne ein einziges Modell zu erzwingen. Sowohl Stripe als auch Notion verwenden Variationen dieses Musters.

Häufige Fehler, die es zu vermeiden gilt

• Wählen Sie eine Datenbank pro Mandant für ein Produkt, das Tausende von Mandanten haben wird.Die Betriebskosten für die Verwaltung Tausender Datenbanken überwiegen die Isolationsvorteile. Wenn es sich bei Ihren Mietern um KMU handelt, die 50 US-Dollar pro Monat zahlen, können Sie sich keine dedizierte Infrastruktur pro Mieter leisten.
• Vergessen Sie, den Umfang Ihrer Testsuite festzulegen.Ihre Integrationstests sollten im Mandantenkontext ausgeführt werden. Wenn Ihre Tests ohne Festlegung eines Mandanten bestanden werden, testen sie einen Codepfad, den Ihre Produktionsbenutzer nicht erreichen.
• RLS-Richtlinien nicht mit gegnerischen Abfragen testen.Schreiben Sie Tests, die versuchen, auf die Daten von Mandant B zuzugreifen, während sie als Mandant A authentifiziert sind. Führen Sie sie in CI aus. Eine bestandene Testsuite ohne mandantenübergreifende Zugriffstests vermittelt falsches Vertrauen.
• Gebäudemietermanagement als nachträglicher Einfall.Mandantenbereitstellung, -konfiguration und -deprovisionierung sind erstklassige Produktfunktionen. Erstellen Sie die Verwaltungstools parallel zum Produkt, nicht erst nach der Markteinführung.
• Überspringen der mandantenbezogenen Protokollierung.Jede Protokollzeile sollte die Mandanten-ID enthalten. Wenn Sie um 2 Uhr morgens ein Produktionsproblem beheben, ist „etwas kaputt“ nutzlos. „Mandant acme_corp hat eine Fremdschlüsseleinschränkung in der Auftragstabelle festgestellt“ ist umsetzbar.

Die Kurzversion

Wählen Sie „Datenbank pro Mandant“, wenn Ihre Architektur von Compliance abhängt. Wählen Sie die Schematrennung, wenn Sie eine moderate Isolation in moderatem Maßstab benötigen. Wählen Sie gemeinsam genutzte Tische mit RLS, wenn Sie Geschwindigkeit und Kosten optimieren möchten. Erstellen Sie vom ersten Tag an Middleware für die Mandantenauflösung. Ordnen Sie Ihre Caches, Protokolle, Hintergrundjobs und Tests dem Mandantenkontext zu. Und überdimensionieren Sie das Isolationsmodell nicht für Ihre aktuelle Phase. Sie können die Isolation verschärfen, wenn Ihre Kunden dies verlangen und Ihr Umsatz dies unterstützt.

Häufig gestellte Fragen