Multi-Tenant-SaaS: Namespace pro Kunde oder Zeile pro Kunde?
Mandantenfähigkeit ist keine Ja-Nein-Frage. Die meisten SaaS-Anbieter brauchen beides: Zeilen für die vielen kleinen Kunden und Namespaces für die wenigen großen.
Jede SaaS steht irgendwann vor derselben Frage: Wie trennen wir Kunden voneinander? Die Antwort entscheidet über Kosten, Sicherheit, Betrieb und darüber, welche Kunden Sie überhaupt gewinnen können. Es gibt zwei Grundmodelle, und die richtige Antwort ist meistens eine Mischung.
Modell A: Eine Zeile pro Kunde
Alle Kunden teilen sich eine Anwendung und eine Datenbank. Jede Tabelle trägt eine Spalte tenant_id, jede Abfrage filtert darauf. Das ist das Modell von Slack, Notion und den meisten B2B-Tools.
Stärken: Ein Deployment für alle, ein Schema, eine Datenbank. Neue Kunden kosten nichts außer einer Zeile. Ein Bugfix erreicht alle sofort.
Schwächen: Ein vergessener Filter zeigt Kunde A die Daten von Kunde B. Eine langsame Abfrage eines großen Kunden bremst alle. Ein Kunde, der seine Daten in einem eigenen Rechenzentrum oder einer eigenen Datenbank sehen will, geht leer aus. Und ein Backup ist immer ein Backup aller.
Modell B: Eine Namespace pro Kunde
Jeder Kunde bekommt seine eigene Instanz der Anwendung: eigene Namespace im Cluster, eigene Datenbank auf der Managed-Instanz, eigene Buckets, eigener Hostname. Das ist das Modell, mit dem Agenturen ein CMS pro Kunde betreiben und mit dem SaaS-Anbieter Enterprise-Kunden bedienen.
Stärken: Harte Trennung. Ein Fehler in einer Abfrage kann keine fremden Zeilen treffen, weil es sie in dieser Datenbank nicht gibt. Ein Kunde kann eine eigene Version, eine eigene Domain, ein eigenes Backup bekommen. Ein Kunde, der kündigt, wird sauber abgebaut.
Schwächen: Jeder Kunde ist ein Deployment. Ein Release muss n-mal ausgerollt werden. Ohne Automatisierung wird das ab zwanzig Kunden zur Vollzeitstelle.
Welches Modell passt zu welchem Kunden?
Kriterium | Zeile pro Kunde | Namespace pro Kunde |
|---|---|---|
Kosten pro Kunde | Nahe null | Ressourcen eines Pods plus Datenbank |
Isolation | Logisch, per Filter | Physisch, per Namespace und Rolle |
Eigene Version pro Kunde | Nein | Ja |
Eigene Domain pro Kunde | Möglich | Selbstverständlich |
Backup pro Kunde | Schwierig | Ein Dump |
Enterprise-Anforderungen | Oft ein Hindernis | Erfüllt |
Betriebsaufwand | Ein Deployment | n Deployments, automatisiert |
Warum gewinnt in der Praxis die Mischung?
Die meisten erfolgreichen SaaS-Anbieter fahren beides. Der Self-Service-Tarif läuft als Zeile pro Kunde: Tausende kleine Kunden, ein Deployment, minimale Kosten. Der Enterprise-Tarif läuft als Namespace pro Kunde: eigene Instanz, eigene Datenbank, eigene Domain, eigener Vertrag über Datenhaltung.
Der Trick ist, dass die Anwendung beides können muss, ohne zwei Codebasen zu pflegen. Eine Instanz mit einem Kunden ist einfach der Sonderfall einer Instanz mit vielen. Die tenant_id bleibt, sie hat in der Enterprise-Instanz nur einen Wert.
Was braucht Modell B, damit es nicht wehtut?
Namespace pro Kunde scheitert nie an Kubernetes, sondern am Onboarding. Wer für jeden Kunden per Hand eine Datenbank anlegt, ein Passwort erzeugt, einen Record setzt und ein Helm-Release installiert, hat nach dem zehnten Kunden ein Skript und nach dem dreißigsten ein Problem. Drei Dinge müssen automatisiert sein:
- Das Anlegen als wiederholbare Pipeline: Datenbank, Buckets, Domain, Workload in fester Reihenfolge, mit Rollback, wenn Schritt vier scheitert.
- Das Verteilen von Releases über alle Kunden, sichtbar, welcher Kunde auf welcher Version steht.
- Das Abbauen mit Backup vorher. Ein Kunde, der kündigt, will seine Daten vielleicht noch, und Sie wollen sie nicht versehentlich gelöscht haben.
Genau dafür gibt es in Clusterward Tenant-Pipelines: Der Stack pro Kunde wird einmal beschrieben, jeder Kunde ist ein Lauf, das Offboarding sichert zuerst und baut dann ab.
Ein Wort zur Datenbank
Für Modell B braucht es nicht eine Datenbankinstanz pro Kunde. Eine Managed-Instanz trägt Hunderte Datenbanken, jede mit eigener Rolle und eigenem Passwort. Das ist der Mittelweg zwischen Kosten und Trennung: Die Instanz wird geteilt, die Daten nicht. Wie Rollen, Rechte und Zusatznutzer dabei funktionieren, steht unter Managed Datenbanken.
Ein Beispiel: Ein CMS-Anbieter wächst
Ein Anbieter betreibt ein Content-Management-System als SaaS. Die ersten hundert Kunden sind Zeilen: eine Datenbank, ein Deployment, eine Domain mit Pfad oder Subdomain pro Kunde. Es läuft, die Kosten pro Kunde sind vernachlässigbar.
Dann kommt eine Behörde. Sie will ihre Inhalte in einer eigenen Datenbank, eine eigene Domain, ein eigenes Backup und die Zusage, dass keine andere Organisation dieselbe Instanz nutzt. Im Zeilenmodell ist das ein Sonderbau. Im Namespace-Modell ist es ein weiterer Lauf derselben Pipeline, nur mit einem anderen Tarif. Der Anbieter führt den zweiten Tarif ein, ohne den Code zu ändern: Die Instanz der Behörde ist eine Instanz mit genau einem Kunden.
Zwei Jahre später hat er dreihundert Zeilen-Kunden und vierzig Namespace-Kunden. Die vierzig bringen mehr Umsatz als die dreihundert. Und der Betrieb der vierzig kostet weniger Aufmerksamkeit als früher der eine Sonderbau, weil jede Instanz gleich aussieht: gleiche Pipeline, gleiches Chart, gleiche Version, nur ein anderer Kunde.
Drei Fehler beim Wechsel auf Namespaces
- Der Namespace-Name aus dem Kundennamen. Wird der Kunde umbenannt, zeigt der Name ins Leere, und das nächste Deployment legt einen zweiten Namespace an. Der Name gehört einmal festgelegt und gespeichert, nie neu berechnet.
- Das Passwort im Onboarding-Protokoll. Wer das Datenbank-Passwort des Kunden in den Lauf schreibt, hat es in jedem Log und jedem Backup des Laufs. Es gehört in die Datenbankverwaltung und wird erst zur Laufzeit gelesen.
- Kein Rollback. Scheitert Schritt vier, bleiben Datenbank, Bucket und Record aus den Schritten eins bis drei stehen. Jeder Schritt braucht seine Umkehrung, und der Rollback läuft rückwärts.
Fazit
Starten Sie mit Zeilen, wenn Sie viele kleine Kunden erwarten. Planen Sie Namespaces ein, sobald der erste Kunde nach eigener Datenbank oder eigener Domain fragt, und das passiert früher, als man denkt. Bauen Sie die Anwendung so, dass beides derselbe Code ist. Und automatisieren Sie das Onboarding, bevor Sie es brauchen.
Welches Modell passt zu Ihrer App? Beschreiben Sie uns kurz Ihre Anwendung und Ihre Kunden. Wir sagen Ihnen, ob Zeile oder Namespace besser passt und wie das Onboarding als Pipeline aussieht. Mandantenmodell besprechen →
Quellen und weiterführende Links
Häufige Fragen
- Bei Zeile pro Kunde teilen sich alle Kunden eine Anwendung und eine Datenbank, jede Tabelle trägt eine tenant_id. Bei Namespace pro Kunde bekommt jeder Kunde eine eigene Instanz: eigene Namespace, eigene Datenbank, eigene Buckets und eigenen Hostname. Das erste ist günstiger, das zweite trennt härter.