Die meisten Architekturentscheidungen sind billiger zu revidieren, als lange über sie zu grübeln. Sie können eine Queue tauschen, ein Framework ersetzen, von einer Cloud in die nächste umziehen — teuer, störend, überlebbar.
Beim Mandantenmodell ist das anders. Wie Sie die Daten eines Kunden von denen des nächsten trennen, berührt jede Abfrage, die Sie je schreiben werden, jede Migration, die Sie je ausführen werden, jedes Backup- und Restore-Verfahren und jeden Sicherheitsfragebogen aus dem Enterprise-Umfeld, den Sie je beantworten werden. Es später zu ändern heißt, die Datenschicht eines laufenden Systems neu zu schreiben, während Kunden davon abhängen.
Eine Stunde jetzt ist es also wert. Hier sind die drei Modelle, ehrlich verglichen.
Modell 1: Shared Schema
Eine Datenbank, ein Satz Tabellen, überall eine tenant_id-Spalte. Jede Abfrage filtert nach Mandant.
- Kosten: mit Abstand die niedrigsten. Eine Datenbank zu betreiben, eine zu sichern, eine zu tunen.
- Betrieb: der einfachste. Eine Migration, einmal ausgeführt, und jeder Mandant ist auf dem aktuellen Schema.
- Skalierung: hervorragend für viele kleine Mandanten. So bedienen Sie zehntausend Kunden profitabel.
- Isolation: die schwächste. Ein einziges fehlendes
WHERE tenant_id = ?ist ein mandantenübergreifendes Datenleck. - Noisy Neighbours: real. Der schwere Report eines Mandanten kann das Erlebnis aller anderen verschlechtern.
- Restore pro Mandant: wirklich schwierig. Die Daten eines einzelnen Kunden aus einem gemeinsamen Backup zurückzuholen gleicht einem chirurgischen Eingriff.
Das Isolationsrisiko ist beherrschbar, aber es muss strukturell beherrscht werden, nicht durch Disziplin. Erzwingen Sie die Mandantentrennung auf der tiefstmöglichen Ebene — Row-Level Security in der Datenbank oder eine Datenzugriffsschicht, in der sich eine ungefilterte Abfrage gar nicht schreiben lässt — niemals dadurch, dass jeder Entwickler daran denkt. Code Review skaliert nicht als Sicherheitskontrolle.
Wenn Sie eine Sache aus diesem Artikel mitnehmen: Machen Sie die ungefilterte Abfrage unschreibbar, nicht bloß unerwünscht. Jeder Shared-Schema-Vorfall, von dem wir gelesen haben, war eine Abfrage, die jemand zu filtern vergessen hat.
Modell 2: Schema pro Mandant
Eine Datenbank, ein eigenes Schema pro Mandant. Derselbe Server, getrennte Namensräume.
- Kosten: weiterhin niedrig — eine Datenbankinstanz.
- Isolation: spürbar besser. Mandantenübergreifender Zugriff erfordert einen bewussten Fehler statt einer vergessenen Klausel.
- Restore pro Mandant: machbar — was im Shared Schema nicht der Fall ist.
- Betrieb: hier liegt der Haken. Migrationen müssen pro Schema laufen, und sie müssen es aushalten, gegen Hunderte davon zu laufen. Eine Migration, die über 400 Schemas hinweg nur halb durchläuft, ist ein wirklich schlechter Nachmittag.
- Skalierungsgrenze: Datenbanken geraten im niedrigen vierstelligen Bereich an Schemas unter Druck — Connection Pooling und der Katalog selbst werden zum Engpass.
Das ist der pragmatische Mittelweg, und er passt zu Plattformen mit einigen Dutzend bis wenigen Hundert Mandanten, von denen jeder wirtschaftlich ins Gewicht fällt. Es ist auch das Modell, das am ehesten aus dem falschen Grund gewählt wird — weil es sich sicherer anfühlt als Shared Schema, ohne dass jemand die dafür nötigen Migrationswerkzeuge eingepreist hätte.
Modell 3: Datenbank pro Mandant
Jeder Mandant bekommt seine eigene Datenbank, manchmal gleich seine eigene Infrastruktur.
- Isolation: die stärkste verfügbare — und die, die sich einem Sicherheitsprüfer am leichtesten erklären lässt.
- Compliance: das Modell, das Anforderungen an die Datenresidenz sauber beantwortet — die Datenbank dieses Mandanten liegt in Frankfurt, die des nächsten in Virginia.
- Backup, Restore und Export pro Mandant: trivial. Ebenso das vollständige Löschen eines Kunden, wenn er geht — was mehr zählt, als Teams erwarten.
- Noisy Neighbours: ausgeschlossen. Kein Mandant kann die Performance eines anderen beeinträchtigen.
- Kosten: die höchsten — und sie wachsen linear mit der Zahl der Mandanten statt mit der Nutzung.
- Betrieb: der aufwendigste. Migrationen, Monitoring, Backups und Upgrades vervielfachen sich, und Sie brauchen echte Automatisierung, bevor Sie echte Mandantenzahlen haben.
Dieses Modell rechtfertigt seine Kosten in genau einer Situation: Enterprise-Kunden, deren Einkauf es verlangt. Wenn Ihre Käufer Sicherheitsfragebögen schicken, die fragen, wo ihre Daten physisch liegen und ob sie sich Infrastruktur mit jemandem teilen, ist das die Antwort, die sie hören wollen — und sie kann über Gewinn oder Verlust des Abschlusses entscheiden.
Die Wahl
Arbeiten Sie diese Fragen der Reihe nach durch:
- Wer ist der Kunde? Tausende kleiner Mandanten sprechen für Shared Schema. Dutzende großer Konzerne sprechen für Datenbank pro Mandant. Eine Mischung spricht für einen Hybrid — siehe unten.
- Was verlangt die Compliance tatsächlich? Nicht, was sich am sichersten anfühlt. Lesen Sie die Verpflichtungen nach. Datenresidenz und keine geteilte Infrastruktur sind konkrete Anforderungen mit konkreten Antworten; diffuse Sorge ist es nicht.
- Zu welchem Preis verkaufen Sie? Datenbank pro Mandant hat einen Sockelbetrag pro Kunde. Wenn dieser Sockel einen spürbaren Anteil Ihres Monatspreises ausmacht, ist das Modell für dieses Segment falsch.
- Wie viel Betriebskompetenz haben Sie? Ein Isolationsmodell zu wählen, das Ihr Team nicht automatisieren kann, heißt, sich für einen Ausfall zu entscheiden.
- Wie wahrscheinlich ist ein Restore pro Mandant? Wenn es plausibel ist, dass ein Kunde seine eigenen Daten versehentlich löscht, wird Shared Schema wehtun.
Der Hybrid — und warum er meist gewinnt
Die meisten erfolgreichen Plattformen landen bei einer Mischung: Shared Schema für die Self-serve-Stufe, dedizierte Datenbanken für Enterprise-Kunden, die dafür zahlen. Das ist ein legitimes und verbreitetes Ziel.
Es ist auch deutlich leichter zu erreichen, wenn Sie es früh einplanen. Eine Schicht zur Mandantenauflösung, die auf eine gemeinsame oder eine dedizierte Datenbank routen kann, kostet am Anfang sehr wenig und ist genau das, was den Hybrid später möglich macht. Sie nachträglich in eine Codebasis einzuziehen, die von einem einzigen Connection String ausging, ist der Punkt, an dem die echten Kosten entstehen.
Wenn Sie unsicher sind, bauen Sie Shared Schema hinter einer Abstraktion, die pro Mandant routen kann. Sie bekommen jetzt das günstige Modell und haben das teure später verfügbar — das Gegenteil der Lage, in der die meisten Teams enden.
Was Sie in jedem Fall festlegt
Welches Modell Sie auch wählen: Diese Entscheidungen verhärten sich mit ihm und verdienen dieselbe Sorgfalt:
- Mandantenidentität in Ihrer Authentifizierungsschicht. Mandantenfähigkeit nachträglich in ein Auth-Modell für einen einzelnen Mandanten einzubauen ist schmerzhaft — entscheiden Sie also vorab, ob ein Nutzer zu mehr als einem Mandanten gehören kann.
- Ob Mandanten-IDs in URLs und APIs sichtbar sind. Das später zu ändern zerstört Integrationen, die Ihre Kunden gebaut haben.
- Wo die Konfiguration pro Mandant liegt. In den Daten des Mandanten oder in einer zentralen Registry? Beides funktioniert; eine Mischung nicht.
- Wie Sie das Zusammenführen oder Aufteilen von Mandanten handhaben. Selten und brutal, wenn das Datenmodell nie damit gerechnet hat — Kunden übernehmen einander tatsächlich.
- Ihr Modell für Hintergrundjobs. Queues pro Mandant, faire Verteilung und Rate Limits pro Mandant lassen sich viel schwerer nachrüsten als von Anfang an einplanen.
Die Frage hinter der Frage
Teams kommen zu dieser Entscheidung meist, weil jemand gefragt hat: Sind unsere Daten sicher? — und greifen zur stärksten verfügbaren Isolation, um sich zu beruhigen. Dieser Reflex ist verständlich, und er ist teuer.
Isolation ist eine Kontrolle unter mehreren. Eine Plattform mit Datenbank pro Mandant, aber schwacher Zugriffskontrolle, ohne Audit-Logging und mit einer gemeinsamen administrativen Hintertür ist weniger sicher als eine sauber gebaute Shared-Schema-Plattform mit Row-Level Security und ordentlicher Autorisierung. Wählen Sie das Mandantenmodell nach Anforderungen und Wirtschaftlichkeit; Sicherheit kaufen Sie separat, bewusst und in mehr als einer Schicht.
Das ist die Art von Entscheidung, die wir durchgehen, bevor eine Zeile Code geschrieben ist — was eine individuelle Node.js-Plattform wirklich kostet zeigt, wie sie ins Budget einfließt. Unser Bereich Node.js-Plattformen und unser Full-Stack-Team tun das gemeinsam mit Kunden statt für sie, weil die Antwort von kaufmännischen Fakten abhängt, die nur sie kennen. Wo die Käufer reguliert sind — wie in Finanzen und im Gesundheitswesen — entscheiden meist die Compliance-Anforderungen.
Häufige Fragen
Mit welchem Mandantenmodell sollte eine neue SaaS starten?
Mit Shared Schema, hinter einer Schicht zur Mandantenauflösung, die später auch auf eine dedizierte Datenbank routen kann. Damit haben Sie heute das günstigste Modell und behalten das teure als Option — das Gegenteil der Sackgasse, in die sich die meisten Teams manövrieren.
Wie verhindern wir mandantenübergreifende Datenlecks im Shared Schema?
Erzwingen Sie die Mandantentrennung unterhalb der Anwendung: Row-Level Security in der Datenbank oder eine Datenzugriffsschicht, in der sich eine ungefilterte Abfrage gar nicht schreiben lässt. Darauf zu vertrauen, dass Entwickler an die WHERE-Klausel denken, ist keine Kontrolle — und Code Review skaliert nicht als Ersatz dafür.
Wann lohnt sich Datenbank pro Mandant trotz der Kosten?
Wenn der Enterprise-Einkauf es verlangt — Datenresidenz in einer benannten Rechtsordnung oder eine dokumentierte Zusicherung, dass keine Infrastruktur geteilt wird. Wenn Ihre Käufer Sicherheitsfragebögen mit genau diesen Fragen schicken, gewinnt dieses Modell den Abschluss. Sonst ist es teure Beruhigung.
Können wir das Mandantenmodell später ändern?
Ja, zu erheblichen Kosten. Es bedeutet, die Datenzugriffsschicht neu zu schreiben, Kundendaten im laufenden Betrieb zu migrieren und jede Abfrage erneut zu prüfen, während die Plattform genutzt wird. Eine früh gebaute Routing-Abstraktion macht das deutlich günstiger; ohne sie wirkt die Entscheidung unumkehrbar.
Wirkt sich Mandantenfähigkeit auf die Performance aus?
Im Shared Schema ja — die schwere Last eines Mandanten kann andere ausbremsen, weshalb Rate Limits pro Mandant und eine faire Job-Verteilung wichtig sind. Dedizierte Datenbanken beseitigen das Problem und ersetzen es durch eine größere Betriebsfläche, die gesund gehalten werden muss.
Lassen Sie die Entscheidung prüfen, bevor Sie bauen
Sagen Sie uns, wer Ihre Kunden sind und was deren Einkauf verlangt, und wir sagen Ihnen, welches Modell Ihr Geschäft tatsächlich braucht — meist das günstigere. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.