Wie lässt sich eine Multi-Tenant-Architektur auf Datenbankebene (Shared Schema vs. Database-per-Tenant) hinsichtlich Isolation und Skalierbarkeit abwägen?

Die Wahl zwischen einem Shared Schema und einer Database-per-Tenant-Strategie hängt primär von den Anforderungen an die Datentrennung und den operativen Aufwand ab.

KriteriumShared SchemaDatabase-per-Tenant
IsolationLogisch (via tenant_id)Physisch (getrennte Instanzen/DBs)
SkalierbarkeitHohe Dichte, primär vertikalHorizontale Verteilung möglich
WartungEinfache Schema-UpdatesKomplexe Migrationen über alle DBs
KostenGeringer RessourcenverbrauchHöherer Overhead pro Tenant
Backup/RestoreNur global möglichMandantenspezifisch möglich

Beim Shared Schema erfolgt die Trennung über eine Diskriminator-Spalte (z. B. tenant_id) in jeder Tabelle. Dies ermöglicht eine maximale Ressourceneffizienz, da eine große Anzahl an Mandanten eine einzige Datenbankinstanz nutzt. Die Isolation ist jedoch rein logisch; ein Programmierfehler in der Abfrage (fehlende WHERE-Klausel) kann zu Datenlecks führen. Die Skalierung erfolgt hier primär vertikal oder durch komplexes Sharding auf Applikationsebene.

Die Database-per-Tenant-Architektur bietet die höchste Isolation. Backups und Restores können mandantenspezifisch durchgeführt werden, ohne andere Nutzer zu beeinflussen. Dies ist bei strengen Compliance-Vorgaben oder individuellen Anpassungswünschen entscheidend. Die Skalierbarkeit ist hier horizontaler Natur, da einzelne Datenbanken auf verschiedene Server verteilt werden können. In unserem Bereich Data Engineering sehen wir oft, dass dieser Ansatz bei Enterprise-Kunden bevorzugt wird, um regulatorische Anforderungen an die Datenhoheit zu erfüllen.

Der operative Aufwand steigt bei der Database-per-Tenant-Lösung signifikant. Schema-Migrationen müssen über alle Instanzen hinweg synchronisiert werden, was robuste CI/CD-Pipelines und automatisierte Migrations-Tools voraussetzt.

Für SaaS-Produkte mit einer hohen Anzahl an kleinen Mandanten ist das Shared Schema aufgrund der Kosteneffizienz und einfachen Wartbarkeit die richtige Wahl. Sobald jedoch Enterprise-Kunden mit spezifischen SLAs, hohen Datenvolumina oder strikten regulatorischen Anforderungen bedient werden, ist der Wechsel zu einer Database-per-Tenant-Architektur alternativlos, da die physische Trennung die einzige zuverlässige Garantie für Datensicherheit und individuelle Performance-Optimierung bietet.

Sergej Wiens

Sergej Wiens

Gründer & Software Architekt