Wie man die Multi-Tenancy-Entscheidung trifft, die man nicht leicht rückgängig machen kann

Multi-Tenancy ist eine der wenigen SaaS-Architekturentscheidungen, die das Wort "unumkehrbar" wirklich verdient. Nicht streng unumkehrbar — jede Architektur lässt sich ändern, bei genug Geld und einem Wartungsfenster — aber teuer genug zu ändern, dass die meisten Teams, die falsch gewählt haben, jahrelang mit der falschen Wahl leben.

Die drei Optionen sind bekannt: gemeinsame Datenbank mit Zeilenebenen-Tenant-Isolation, Schema-per-Tenant innerhalb einer gemeinsamen Datenbank oder Datenbank-per-Tenant. Die meisten Artikel zu diesem Thema enden damit, sie aufzulisten. Die interessante Frage ist, welche zu welchem Unternehmen passt — und die Antwort hängt von Eigenschaften eurer Kunden ab, nicht von Eigenschaften eures Codes.

Wie die drei Modelle tatsächlich aussehen

Kurz, für ein gemeinsames Vokabular:

Gemeinsame Datenbank, Zeilenebenen-Isolation. Eine Datenbank. Ein Schema. Jede Tabelle hat eine tenant_id-Spalte. Jede Abfrage hat eine WHERE tenant_id = ?-Klausel. Tenant-Isolation wird auf Anwendungsebene erzwungen. Das ist der Standard für die meisten SaaS-Produkte und am einfachsten zu bauen.

Schema-per-Tenant. Eine Datenbank. Ein separates Schema pro Kunde. Die Anwendung verbindet sich mit einem tenantspezifischen Suchpfad oder schema-qualifizierten Abfragen. Isolation wird durch die Datenbankgrenze zwischen Schemas erzwungen. Backups, Wiederherstellungen und Migrationen passieren pro Schema.

Datenbank-per-Tenant. Eine separate Datenbank pro Kunde. Die Anwendung pflegt einen Pool von Verbindungen, wählt die richtige Datenbank für die Anfrage und routet entsprechend. Isolation wird durch die stärkste Grenze erzwungen, die die Datenbank-Engine bietet.

Es gibt auch Varianten — gemeinsame Datenbank mit Row-Level-Security-Policies (Postgres RLS), hybride Modelle, bei denen manche Tabellen geteilt und andere per-Tenant sind, und verwaltete Lösungen wie Aurora Serverless oder DynamoDB-Tabellen per Tenant. Das Entscheidungs-Framework gilt auch für diese.

Die vier Faktoren, die entscheiden

Vier Eigenschaften eures Unternehmens bestimmen, welches Modell passt. Die meisten Teams gewichten den dritten über und die anderen unter.

Verteilung der Tenant-Größe. Wenn eure Tenants in der Größe etwa gleich sind — kleine Unternehmen, die vielleicht je 100 MB Daten verwenden — funktioniert eine gemeinsame Datenbank gut, und die operative Einfachheit ist enorm. Wenn eure Tenants um drei Größenordnungen variieren — manche haben 1 MB, manche haben ein Terabyte — beginnt die gemeinsame Datenbank pathologische Abfragepläne für die kleinen Tenants zu produzieren, weil die Indexstatistiken von den großen dominiert werden. Schema-per-Tenant oder Datenbank-per-Tenant wird strukturell besser.

Noisy-Neighbor-Risiko. Manche Kunden-Workloads sind in einer Weise burstig, die andere Kunden betrifft. Eine Reporting-Abfrage, die die gesamte Geschichte eines Tenants durchsucht, kann die gemeinsame Datenbank blockieren, wenn sie schlecht gebaut ist. In einem gemeinsamen Modell beeinträchtigt der Fehler eines Kunden alle anderen. Die Kosten der Isolation sind real, aber so auch die Kosten, sie nicht zu haben — für Kunden, deren Arbeit in der Last ungleichmäßig ist.

Regulatorische und vertragliche Einschränkungen. Manche Kunden werden einen Enterprise-Vertrag nur unterzeichnen, wenn ihre Daten in einer Datenbank liegen, die allein ihnen gehört. Manche Branchen — Gesundheitswesen, Finanzdienstleistungen — machen das zur Standard-Erwartung statt zur Ausnahme. Wenn euer Vertriebsteam das in den nächsten zwei Jahren antreffen wird, bedeutet jetzt eine gemeinsame Datenbank zu bauen, später eine Migration. Die Migration ist der teure Teil der gesamten Architekturentscheidung.

Operative Reife. Eine gemeinsame Datenbank ist eine Sache, die man sichert, eine Sache, die man patcht, eine Sache, die man migriert. Tausend Datenbanken sind tausend Sachen. Datenbank-per-Tenant funktioniert nur, wenn eure operativen Tools die tausend als Flotte behandeln können — automatisierte Provisionierung, automatisches Patchen, automatische Backup-Überprüfung, automatisches Kostenmonitoring. Teams, die Datenbank-per-Tenant ohne diese Tools wählen, ertrinken innerhalb eines Jahres im Betrieb.

Das Entscheidungs-Framework

Die vier Faktoren ehrlich abbilden:

• Tenants sind gleichmäßig in der Größe, keine Noisy-Neighbor-Bedenken, kein regulatorischer Druck, kleines Ops-Team → gemeinsame Datenbank. Das ist die richtige Antwort für die meisten frühen SaaS-Produkte.

• Tenants variieren um eine oder zwei Größenordnungen, manche sind groß genug, um Noisy-Neighbor-Probleme zu verursachen, kein regulatorischer Druck → Schema-per-Tenant. Gibt euch Isolation ohne die operative Explosion separater Datenbanken.

• Tenants umfassen Enterprise-Kunden, die Datenisolation erfordern, regulatorische Einschränkungen sind im Scope, Ops-Team hat Fleet-Tooling → Datenbank-per-Tenant. Oft die richtige Antwort für sales-geführtes Enterprise-SaaS, fast immer die falsche Antwort für Self-Serve-SaaS.

Das hybride Modell — teils geteilt, teils per-Tenant — ist oft das eigentliche Ziel nach einigen Jahren des Wachstums. Es ist kein Modell, mit dem man anfängt. Es ist das Ergebnis, an einem Ort anzufangen und zu entdecken, dass das andere Modell für eine bestimmte Untergruppe von Kunden richtig ist.

Was man jetzt bauen sollte, auch wenn man später wechselt

Ein paar Gewohnheiten machen die eventuelle Migration günstiger, unabhängig davon, mit welchem Modell man anfängt.

Tenant-ID von Tag eins als erstklassiges Konzept im Domain-Modell machen. Selbst in einem Einzel-Tenant-Prototyp sollte das Datenmodell sie haben. Das nachzurüsten ist schmerzhaft; es einzuplanen ist kostenlos.

Tenant-Scoping als einzelnes Stück Code behandeln, nicht als WHERE-Klausel, die überall verstreut ist. Eine Repository-Schicht oder ein Query-Builder, der den Scope automatisch injiziert, macht Tenant-Isolierungs-Bugs sehr selten. Handgeschriebene Abfragen, die sich "erinnern", den Filter einzufügen, machen Tenant-Isolierungs-Bugs unvermeidlich. Wir haben echtes Geld gesehen, das darüber verloren ging.

Die Connection-Pooling-Abstraktion so bauen, dass sie per-Tenant-Routing unterstützt, auch wenn man es nicht nutzt. Wenn der Migrationstag kommt, ist die Verkabelung bereits vorhanden. Das ist eines der günstigsten Stücke vorausschauender Investition, die man machen kann.

Alle sechs Monate eine "Was würde die Migration kosten?"-Übung durchführen. Nicht weil man es bald tun wird, sondern weil die Antwort driftet, während das System wächst. Eine Migration, die heute eine Woche kosten würde, könnte in achtzehn Monaten ein Quartal kosten. Die Zahl zu kennen lässt einen bewusst entscheiden, ob man handelt.

Die ehrliche Zusammenfassung

Die Multi-Tenancy-Wahl ist wirklich schwer — und es ist wirklich wert, sich Zeit dafür zu nehmen. Es ist keine Entscheidung, die das Engineering-Team allein treffen kann. Die Antwort hängt davon ab, an wen man verkauft und wie sich das in den nächsten drei Jahren ändern wird. Vertriebsleitung und Engineering-Leitung in denselben Raum bringen, bevor man entscheidet. Die Teams, die Geld mit dieser Entscheidung verlieren, verlieren es meistens in dem Raum, wo die Entscheidung ein Standard war, keine Diskussion.