16. September 2026
Die meisten Rails-SaaS-Projekte, die ich sehe, treffen ihre Multi-Tenancy-Entscheidung nicht bewusst – sie geschieht implizit, weil account_id-Spalten der naheliegendste Weg sind, eine erste Kundin von einer zweiten zu unterscheiden. Das ist selten falsch. Aber es ist eine Architekturentscheidung mit echten Konsequenzen, die getroffen wird, ohne dass sie als Entscheidung wahrgenommen wird – und genau das macht sie später teuer zu korrigieren.
Die drei Grundmuster
Row-Level (Shared Database, Shared Schema). Jede Tabelle bekommt eine tenant_id-Spalte, jede Query wird um WHERE tenant_id = ? ergänzt, meist über einen Default Scope oder ein Gem wie acts_as_tenant. Das ist der Standardweg, und aus gutem Grund: eine Migration betrifft alle Kundinnen gleichzeitig, das Hosting bleibt trivial, und für die ersten hundert Kundinnen ist der Overhead pro Tenant praktisch null.
Schema-per-Tenant. Jede Kundin bekommt ein eigenes Postgres-Schema in derselben Datenbank. Isolation ist deutlich stärker – ein vergessener Tenant-Scope in einer neuen Query kann keine fremden Daten mehr zurückgeben, weil die Tabelle physisch nicht sichtbar ist. Der Preis: Migrationen müssen über alle Schemas iterieren, und Connection-Handling wird komplexer (Gems wie apartment lösen das, bringen aber eigene Wartungslast mit).
Datenbank-per-Tenant. Maximale Isolation, eigene Backups, eigene Skalierung pro Kundin – und der höchste Betriebsaufwand. Sinnvoll, wenn eine einzelne Enterprise-Kundin vertraglich verlangt, dass ihre Daten physisch getrennt liegen, oder wenn Compliance-Anforderungen (Datenresidenz in einer bestimmten Region) das erzwingen. Für die meisten SaaS-Produkte in der Wachstumsphase ist das ein Aufwand, der sich vor Kundin Nummer fünfzig kaum rechnet.
Warum die Entscheidung so früh fällt, obwohl sie sich früh spät anfühlt
Das Muster, das ich in Audits regelmäßig sehe: Ein Team startet mit Row-Level, weil es am Tag eins schneller zu bauen ist – berechtigterweise. Aber niemand entscheidet das bewusst als "Row-Level bis zu Meilenstein X, dann Migration auf Schema-per-Tenant". Stattdessen wächst die Anwendung organisch in eine Architektur hinein, die für die erste Kundin richtig war und für die fünfzigste falsch ist, ohne dass es einen Moment gab, an dem jemand "jetzt" gesagt hat.
Der Wechsel von Row-Level zu Schema-per-Tenant nach dem Launch ist keine Migration im normalen Sinn – es ist ein Rewrite der Datenzugriffsschicht bei laufendem Betrieb, mit echten Kundendaten, ohne Downtime-Fenster, das eine wachsende SaaS sich leisten will. Genau deshalb lohnt es sich, die Entscheidung bewusst zu treffen, bevor die erste zahlende Kundin an Bord ist – nicht weil Row-Level meistens falsch wäre, sondern weil die spätere Korrektur so viel teurer ist als die frühe, bewusste Wahl.
Die drei Fragen, die die Entscheidung tatsächlich treiben
- Gibt es eine vertragliche oder regulatorische Anforderung an physische Datentrennung? Wenn ja, ist die Antwort meistens Datenbank-per-Tenant, unabhängig von der restlichen Architektur – das ist keine technische, sondern eine rechtliche Entscheidung.
- Wie teuer ist ein Datenleck zwischen zwei Kundinnen für das Geschäftsmodell? Bei einem internen Tool für zehn Teams ist ein vergessener Scope ein Bug. Bei einer SaaS für Anwaltskanzleien ist er ein Vorfall, der das Unternehmen beenden kann. Je höher dieser Preis, desto eher lohnt sich die zusätzliche Isolation von Schema-per-Tenant, auch wenn sie am Anfang unnötig komplex wirkt.
- Wie viele Tenants werden es in zwei Jahren realistisch sein? Bei fünf großen Enterprise-Kundinnen ist Datenbank-per-Tenant machbar. Bei fünftausend Self-Service-Kundinnen wird dieselbe Strategie zum Betriebsproblem, weil jede Migration fünftausendmal laufen muss.
Keine dieser drei Fragen braucht eine Codebase, um beantwortet zu werden – sie lassen sich am ersten Projekttag klären, mit dem Product Owner statt mit dem Debugger. Das macht diese Architekturentscheidung zu einer der wenigen in einem SaaS-Projekt, die man vollständig VOR der ersten Zeile Code treffen kann und sollte.