Was bedeutet Multi-Tenancy in Laravel?

Multi-Tenancy (Mandantenfähigkeit) heißt: Eine Anwendung und eine Codebase bedienen mehrere Kunden – die Mandanten –, deren Daten strikt voneinander getrennt bleiben. Jeder Mandant erlebt die Anwendung, als wäre sie nur für ihn da: eigene Benutzer, eigene Daten, oft eigene Subdomain und eigenes Branding. Typische Fälle sind SaaS-Produkte und Kundenportale.

Single Database oder eine Datenbank pro Mandant?

Eine gemeinsame Datenbank mit Tenant-Spalte ist einfacher zu betreiben und für die meisten Projekte der richtige Start – die Trennung passiert in der Anwendung. Eine Datenbank pro Mandant isoliert härter und macht Export oder Löschung einzelner Mandanten trivial, kostet aber deutlich mehr Betriebsaufwand: Migrationen, Backups und Verbindungen multiplizieren sich mit jedem Mandanten. Harte Isolationsanforderungen (Branche, Vertrag, Behörde) sind der häufigste Grund für den teureren Weg.

Welches Tenancy-Package für Laravel?

Die beiden etablierten sind stancl/tenancy und spatie/laravel-multitenancy. stancl/tenancy nimmt dir viel automatisch ab – bis hin zu getrennten Datenbanken je Mandant –, greift dafür aber tief in die Anwendung ein. Das Spatie-Package ist bewusst schlanker und überlässt dir mehr Entscheidungen. Und manchmal ist die richtige Antwort gar kein Package: Bei wenigen, im Code bekannten Mandanten reicht oft eine saubere Modul-Struktur.

Was kostet eine mandantenfähige Laravel-Anwendung?

Mandantenfähigkeit ist kein Feature, das man am Ende dazubucht, sondern eine Architekturentscheidung, die viele Stellen der Anwendung betrifft: Datenmodell, Authentifizierung, Jobs, Backups, Onboarding. Nachträglich einbauen ist um ein Vielfaches teurer als von Anfang an mitdenken. Die Kostentreiber sind weniger die Tenant-Logik selbst als das Drumherum – automatisiertes Onboarding, Abrechnung je Mandant und die Teststrategie, die die Datentrennung dauerhaft absichert.

Laravel Multi-Tenancy: Architektur, Pakete und Kosten im Überblick

Sobald eine Webanwendung mehr als einen Kunden bedienen soll, steht die Frage im Raum: eine Installation pro Kunde – oder eine Anwendung für alle? Die zweite Variante heißt Multi-Tenancy, auf Deutsch Mandantenfähigkeit, und sie ist das Fundament fast jedes SaaS-Produkts und vieler Kundenportale.

Laravel kann das gut. Die eigentliche Frage ist nicht ob, sondern wie – denn unter dem einen Begriff stecken sehr unterschiedliche Architekturen mit sehr unterschiedlichen Folgekosten. Dieser Artikel sortiert die Optionen, benennt die Werkzeuge und sagt ehrlich, wann die aufwendigste Lösung die falsche ist.

Was Multi-Tenancy bedeutet

Ein Mandant (Tenant) ist ein Kunde deiner Anwendung mit eigenem, abgeschottetem Datenraum: eigene Benutzer, eigene Inhalte, oft eigene Subdomain (kunde-a.deinprodukt.de) und eigenes Branding. Die Anwendung selbst existiert nur einmal – ein Deployment, eine Codebase, ein Release für alle.

Der Gegenentwurf wäre eine Installation pro Kunde. Das klingt nach sauberer Trennung, skaliert aber nicht: Jedes Update muss n-mal ausgerollt werden, jeder Bugfix n-mal, jede Server-Konfiguration lebt n-mal. Ab einer Handvoll Kunden gewinnt fast immer die mandantenfähige Architektur – wenn sie sauber gebaut ist.

Die drei Architekturen

Multi-Tenancy entscheidet sich an einer Frage: Wo verläuft die Datengrenze? Drei Antworten haben sich etabliert:

1. Gemeinsame Datenbank, Tenant-Spalte. Alle Mandanten teilen sich Tabellen; jede Zeile trägt eine tenant_id, und die Anwendung filtert jede Abfrage darauf – in Laravel typischerweise über globale Eloquent-Scopes. Das ist die einfachste und günstigste Variante: eine Datenbank, ein Backup, eine Migration. Ihre Schwäche ist zugleich ihr Risiko: Die Trennung existiert nur in der Anwendungslogik. Ein vergessener Scope, eine handgeschriebene Query ohne Filter – und Mandant A sieht Daten von Mandant B.

2. Eine Datenbank pro Mandant. Jeder Mandant bekommt seine eigene Datenbank; die Anwendung wechselt je nach Request die Verbindung. Die Isolation ist strukturell statt logisch – ein vergessener Filter kann keine fremden Daten mehr treffen, weil sie physisch woanders liegen. Auch Export, Restore oder DSGVO-Löschung eines einzelnen Mandanten werden trivial. Der Preis: Migrationen, Backups und Monitoring multiplizieren sich mit der Mandantenzahl, und das Onboarding eines neuen Kunden heißt „Datenbank provisionieren”, nicht „Zeile anlegen”.

3. Ein Schema pro Mandant. Der Mittelweg, vor allem mit PostgreSQL: eine Datenbank, aber getrennte Schemata je Mandant. Härtere Trennung als die Tenant-Spalte, weniger Betriebsaufwand als getrennte Datenbanken – dafür an das Datenbanksystem gebunden und operativ anspruchsvoller als Variante 1.

Die Faustregel aus unserer Projektpraxis: Variante 1 ist der richtige Start, solange nichts Härteres verlangt wird. Harte Isolationsanforderungen kommen selten aus der Technik – sie kommen aus Verträgen, Branchenregeln oder von Kunden, die im Audit die Frage stellen: „Liegen unsere Daten in derselben Tabelle wie die des Wettbewerbers?”

Die Werkzeuge: stancl/tenancy, Spatie – oder gar kein Package

Im Laravel-Ökosystem haben sich zwei Packages etabliert, mit gegensätzlicher Philosophie:

stancl/tenancy („Tenancy for Laravel”) will Multi-Tenancy weitgehend automatisch lösen: Tenant-Erkennung über Domain oder Subdomain, automatisches Umschalten von Datenbankverbindung, Cache, Dateisystem und Queues in den Tenant-Kontext. Das ist mächtig – gerade für Variante 2 mit getrennten Datenbanken – und bedeutet zugleich: Das Package greift tief in die Anwendung ein, und du solltest verstehen, was es tut, bevor du dich darauf verlässt.

spatie/laravel-multitenancy geht den umgekehrten Weg: bewusst schlank, ein nachvollziehbarer Kern („finde den aktuellen Tenant, führe Tasks beim Wechsel aus”), der Rest bleibt deine Entscheidung. Weniger Magie, mehr Eigenverantwortung – gut, wenn du die Kontrolle behalten willst und deine Anforderungen von den Standardannahmen größerer Packages abweichen.

Und manchmal: keins von beiden. Ein Tenancy-Package lohnt sich, wenn Mandanten zur Laufzeit entstehen und einen echten Lebenszyklus haben – Self-Service-Registrierung, eigene Benutzerwelten, Abrechnung je Mandant. Sind die „Mandanten” dagegen wenige und im Code bekannt, ist ein Package oft die falsche erste Abstraktion. Wie das konkret aussieht, zeigt unser Rentlytics-Projekt: mehrere kommunale Mietspiegelrechner in einer Laravel-Codebase, getrennt über Modul-Service-Provider statt Tenancy-Package – die kleinste Architektur, die die echten Grenzen schützt.

Der Punkt, an dem Multi-Tenancy scheitert: Isolation

Das größte Risiko einer mandantenfähigen Anwendung ist nicht Performance und nicht Skalierung – es ist der Datenleck-Bug: Mandant A sieht Daten von Mandant B. Genau ein solcher Fehler kann das Vertrauen kosten, von dem ein SaaS-Produkt lebt.

Deshalb gehört die Isolation nicht in die Kategorie „machen wir schon richtig”, sondern in die Architektur und die Tests:

Jede datenführende Abfrage läuft über den Tenant-Kontext – globale Scopes statt Disziplin-Appelle an jeden Entwickler. Handgeschriebene Queries und Reports sind die klassischen Ausreißer.
Der Tenant-Kontext gilt überall, nicht nur im Web-Request. Queue-Jobs, geplante Tasks, Exporte und Artisan-Commands laufen außerhalb des Requests – wer dort den Mandanten nicht explizit setzt, arbeitet im Zweifel auf den falschen Daten.
Tests, die die Grenze angreifen. Ein guter Testsatz versucht aktiv, als Mandant A an Daten von Mandant B zu kommen – über IDs in URLs, über Filter, über Exporte. Solche Tests sind billig geschrieben und werden mit jedem Feature wertvoller.
Dateien nicht vergessen. Uploads, generierte PDFs und Exporte brauchen dieselbe Trennung wie Datenbankzeilen – ein erratbarer Dateipfad ist dasselbe Leck in anderem Gewand.

Was Multi-Tenancy kostet

Die ehrliche Antwort: Die Tenant-Logik selbst ist der kleinere Teil. Teuer wird das Drumherum – und zwar abhängig davon, wie viel „Produkt” dein Produkt sein soll:

Onboarding. Legt ein Admin neue Mandanten von Hand an, oder registrieren sich Kunden selbst – mit automatischer Provisionierung, Subdomain und Willkommensstrecke? Zwischen beidem liegt ein Vielfaches an Aufwand.
Abrechnung. Je Mandant abrechnen, Pläne, Testphasen, Zahlungsanbieter – ein eigenes Arbeitspaket, kein Nebeneffekt.
Betrieb. Bei getrennten Datenbanken: Migrationen über alle Mandanten orchestrieren, Backups je Mandant, Monitoring. Das ist laufender Aufwand, kein einmaliger.
Die Nachrüst-Falle. Mandantenfähigkeit betrifft Datenmodell, Auth, Jobs und Speicher gleichzeitig. Sie nachträglich in eine gewachsene Single-Tenant-Anwendung einzubauen ist um ein Vielfaches teurer, als sie von Anfang an mitzudenken – selbst wenn der erste Release nur einen einzigen Mandanten hat.

Warum wir für solche Produkte trotzdem fast immer bei Laravel landen, haben wir in Warum Laravel für Unternehmen? begründet – das Ökosystem aus Auth, Queues, Policies und Testing ist genau das Fundament, das Mandantenfähigkeit braucht.

Entscheidungshilfe nach Situation

SaaS-Produkt mit Self-Service, wachsende Kundenzahl → gemeinsame Datenbank mit Tenant-Spalte als Start, Tenancy-Package für den Lebenszyklus; getrennte Datenbanken erst, wenn Verträge oder Compliance es verlangen.
Kundenportal für einen definierten Kundenkreis → meist Variante 1 mit sauberen Scopes; ein Package nur, wenn Mandanten wirklich einen Lebenszyklus haben.
Branche mit harten Isolationsanforderungen (Gesundheits-, Finanzdaten, Behörden) → Datenbank oder Schema pro Mandant von Anfang an – die strukturelle Trennung ist hier das Verkaufsargument, nicht der Kostenpunkt.
Wenige, bekannte Varianten statt echter Mandanten → kein Tenancy-Package, sondern Modul-Struktur – siehe das Rentlytics-Muster.

Ehrliches Fazit

Multi-Tenancy ist eine Architekturentscheidung, keine Package-Installation. Die Wahl zwischen gemeinsamer Datenbank, Schema- oder Datenbank-Trennung sollte aus deinen Isolationsanforderungen kommen, nicht aus der Feature-Liste eines Tools – und die Isolation selbst gehört in Scopes und Tests, nicht in gute Vorsätze. Wer das von Anfang an mitdenkt, bekommt mit Laravel eine Basis, die vom ersten Kunden bis zum echten SaaS trägt.

Du planst ein SaaS-Produkt oder Kundenportal? Wir bauen mandantenfähige Laravel-Anwendungen – von der Architekturentscheidung bis zum Betrieb. Ehrliche Einschätzung vorab, welche Variante dein Fall wirklich braucht: Erzähl uns von deinem Vorhaben. Mehr zu unserer Arbeitsweise auf der Seite unserer Laravel-Agentur.