Sobald eine Anwendung mehr als einen Kunden bedient, stellt sich die Architekturfrage: Wie trennen wir Mandanten sauber, ohne den Betrieb zu verteuern? Die Antwort prägt Skalierung, Kosten und Compliance für Jahre.
Drei Modelle
- Shared Database, Shared Schema — alle Mandanten in denselben Tabellen,
getrennt per
tenant_id. Günstig und einfach zu betreiben, aber jede Query muss den Filter sauber setzen. Ein Fehler = Datenleck. - Shared Database, Separate Schemas — ein Schema pro Mandant. Bessere Isolation, moderater Aufwand, gut bis in den niedrigen vierstelligen Bereich.
- Database per Tenant — maximale Isolation und einfache Lösch-/Export- pflichten (DSGVO), dafür höherer Betriebsaufwand.
Es gibt kein „richtig“ — nur ein „richtig für Ihre Last, Ihre Regulierung und Ihr Team“.
Worauf es wirklich ankommt
Nicht das Modell allein entscheidet, sondern die Disziplin in der Datenschicht: ein zentraler Tenant-Kontext, der nie umgangen werden kann, plus Tests, die genau das erzwingen. Wir starten meist mit Shared Schema und einer harten Tenant-Guard — und halten den Pfad zu stärkerer Isolation offen, falls ein Kunde sie braucht.