Mandantenfähige Webapps mit Laravel
Mandantenfähigkeit ist die Basis jedes skalierbaren SaaS-Produkts. Mit Laravel lässt sich Multi-Tenancy auf verschiedenen Wegen umsetzen – von der einfachen Organisations-Kennung in einer gemeinsamen Datenbank bis zur vollständigen Datenbank-Isolation. Als Laravel-Agentur wählen wir je nach Anforderung den passenden Ansatz – mit einer eigenen Implementierung oder dem bewährten Package Tenancy for Laravel.
Mandantenfähigkeit (Multi-Tenancy) bedeutet: Eine Anwendung, viele Kunden – jeder mit eigenen Daten, Einstellungen und Nutzern. Für die meisten Projekte empfehlen wir eine gemeinsame Datenbank mit Organisations-Kennung. Bei besonderen Anforderungen setzen wir auf vollständige Datenbank-Isolation.
Dieser Guide zeigt, welche Multi-Tenancy-Architektur zu Ihrem Projekt passt – und warum die Wahl zwischen gemeinsamer und getrennter Datenbank eine Entscheidung ist, die sich später kaum noch korrigieren lässt.
Besonders für SaaS-Produkte, Kundenportale und Webplattformen ist Multi-Tenancy die architektonische Grundlage für skalierbares Wachstum.
Was ist Mandantenfähigkeit?
Eine Anwendung, viele Kunden – jeder in seinem eigenen geschützten Bereich. Stellen Sie sich ein Bürogebäude vor: Jedes Unternehmen hat sein eigenes Büro mit eigenem Schlüssel, nutzt aber gemeinsam Aufzüge, Heizung und Hausmeister. Genauso funktioniert mandantenfähige Software: Jeder Kunde (Mandant) hat seinen eigenen abgeschlossenen Bereich, teilt sich aber die technische Infrastruktur.
Der größte Vorteil: Sie sparen Entwicklungs- und Wartungskosten. Updates müssen nur einmal eingespielt werden und stehen sofort allen Nutzern zur Verfügung. Neue Kunden können Sie in Sekunden freischalten. So bleibt Ihr Budget planbar, während Ihre Software mit jedem Kunden wächst.
Welche Multi-Tenant-Architektur passt zu Ihrem Projekt?
Die Antwort hängt von Ihren Anforderungen ab: Datensensibilität, rechtliche Vorgaben, erwartete Mandantenzahl. Diese Fragen klären wir gemeinsam, bevor wir mit der Entwicklung beginnen. Grundsätzlich gibt es zwei Wege:
Gemeinsame Datenbank – alle Mandanten in einer Datenbank, getrennt durch eine Organisations-Kennung. Einfacher, günstiger, wartungsarm.
Getrennte Datenbanken – jeder Mandant hat seine eigene Datenbank. Maximale Isolation, aber deutlich höherer Aufwand und Kosten.
In den meisten Fällen ist die gemeinsame Datenbank die bessere Wahl. Getrennte Datenbanken sind nur dann notwendig, wenn strenge regulatorische Anforderungen eine physische Datentrennung vorschreiben – etwa bei besonders sensiblen Gesundheits- oder Finanzdaten.
Wie funktioniert Multi-Tenancy mit einer gemeinsamen Datenbank?
Alle Mandanten teilen sich eine Datenbank. Die Trennung erfolgt über eine eindeutige Kennung. Technisch wird jedem Datensatz eine Organisations-ID zugewiesen – ähnlich wie beschriftete Aktenordner in einem gemeinsamen Aktenschrank. Die Software stellt automatisch sicher, dass jeder Mandant nur seine eigenen Daten sieht.
Ein häufiger Einwand: "Ist eine gemeinsame Datenbank nicht unsicherer?" Die kurze Antwort: Nein, wenn die Software sauber entwickelt ist. Praktisch jeder Online-Shop arbeitet nach demselben Prinzip. Entscheidend ist die Qualität der Software und eine lückenlose Testabdeckung – getrennte Datenbanken sind kein Ersatz für saubere Entwicklungsarbeit.
Die Vorteile im Überblick:
Neue Kunden in Sekunden freischaltbar – ein Registrierungsprozess genügt
Updates einmal einspielen, alle Mandanten profitieren sofort
Keine tiefen Eingriffe ins Framework nötig – Laravel-Upgrades bleiben unkompliziert
Geringere Hosting-Kosten als bei getrennten Datenbanken
Wann brauchen Sie getrennte Datenbanken?
Nur wenn regulatorische oder vertragliche Vorgaben eine physische Datentrennung zwingend vorschreiben. Das betrifft in der Praxis wenige Branchen – etwa Finanzdienstleister mit BaFin-Auflagen oder Gesundheitsunternehmen mit besonderen Datenschutzanforderungen.
Wichtig: Einmal gewählt, lässt sich diese Architektur kaum noch rückgängig machen. Deshalb prüfen wir zu Projektbeginn genau, ob eine getrennte Datenbankarchitektur wirklich notwendig ist. Die Konsequenzen sind erheblich:
Die Software muss jederzeit wissen, welcher Mandant aktiv ist – in jedem Bereich der Anwendung
Für jeden neuen Kunden muss eine eigene Datenbank eingerichtet werden – automatisierbar, aber komplex
Migrations und Schema-Änderungen müssen über alle Datenbanken hinweg koordiniert werden
Höhere Infrastruktur- und Wartungskosten über die gesamte Lebensdauer
Wie setzen wir Multi-Tenancy in der Praxis um?
Je nach Anforderung wählen wir einen eigenen Ansatz oder setzen auf das bewährte Package Tenancy for Laravel.
Eigene Implementierung mit Laravel-Bordmitteln: Für die gemeinsame Datenbank braucht es kein externes Package. Laravel bringt alles mit: Im Kern steht eine Organisations-Tabelle, an die alle anderen Daten geknüpft werden. Über Eloquent Global Scopes wird automatisch sichergestellt, dass jede Abfrage nur die Daten des aktiven Mandanten zurückgibt. Dieser Ansatz ist schlank, transparent und lässt sich exakt auf Ihre Anforderungen zuschneiden.
Tenancy for Laravel (stancl/tenancy): Wenn getrennte Datenbanken nötig sind oder Sie ein erprobtes, Community-getragenes Package bevorzugen, setzen wir auf Tenancy for Laravel (GitHub). Das Package unterstützt sowohl Single-Database als auch Multi-Database-Architekturen und bietet Tenant-Identifikation über Domains, Subdomains oder Pfade, automatische Datenbank-Erstellung für neue Mandanten, Tenant-spezifische Konfiguration und Events, sowie eine aktive Community mit regelmäßigen Updates.
Die Entscheidung zwischen eigenem Ansatz und Package hängt von der Komplexität ab: Für einfache Mandantentrennung in einer Datenbank ist die eigene Implementierung oft die bessere Wahl – weniger Abhängigkeiten, weniger Konfiguration, vollständige Kontrolle. Für komplexe Szenarien mit Datenbank-Isolation, Domain-basierter Tenant-Erkennung und automatisiertem Onboarding spart das Package erheblich Entwicklungszeit.
Warum ist Testing bei mandantenfähiger Software so wichtig?
Weil ein einziger Fehler in der Datentrennung bedeutet, dass ein Mandant die Daten eines anderen sehen kann. Das ist nicht nur ein Bug – es ist ein Sicherheitsvorfall und ein potenzieller DSGVO-Verstoß.
Deshalb ist Test Driven Development (TDD) bei mandantenfähigen Systemen unverzichtbar. Jede Datenbankabfrage, jeder API-Endpunkt und jede Benutzeraktion wird automatisiert darauf getestet, dass die Mandantentrennung lückenlos funktioniert. Diese Investition in gründliche Tests zahlt sich langfristig aus – sie ist der Unterschied zwischen einer Software, der Ihre Kunden vertrauen, und einer, die Schlagzeilen macht.
Wie sieht Multi-Tenancy in der Praxis aus?
Wir haben Multi-Tenancy in verschiedenen Kundenprojekten umgesetzt. Ein Beispiel ist unsere Multi-Tenant-Architektur mit Statamic: Eine Statamic-basierte Plattform, bei der mehrere Marken und Websites aus einer einzigen Installation heraus betrieben werden – mit getrennten Inhalten, eigenem Design und individuellen Domains pro Mandant.
Ob CRM-System, Kundenportal oder SaaS-Plattform – mandantenfähige Architekturen sind einer unserer Schwerpunkte als Laravel-Agentur. Auch FilamentPHP, das Admin-Panel-Framework, das wir für unsere Projekte einsetzen, bringt natives Multi-Tenancy mit – ein weiterer Baustein im Laravel-Ökosystem, der mandantenfähige Entwicklung beschleunigt.
Weiterführende Ressourcen
Im Rahmen der Laracon 2017 wurde ein grundlegender Vortrag zum Thema Multi-Tenancy gehalten, der die architektonischen Grundlagen gut erklärt:
Unsere Empfehlung
Eine gemeinsame Datenbank ist für die meisten Projekte die richtige Wahl. Sie ermöglicht schnelles Wachstum, einfache Wartung und hält die Kosten überschaubar. Sofern keine rechtlichen Vorgaben eine physische Datentrennung verlangen, empfehlen wir die Ein-Datenbank-Lösung.
Wir wählen den Ansatz, der zu Ihrem Projekt passt: eine schlanke eigene Implementierung für einfache Szenarien oder Tenancy for Laravel für komplexe Anforderungen mit Datenbank-Isolation und automatisiertem Onboarding.
Sie möchten eine mandantenfähige Software entwickeln lassen? Sprechen Sie mit uns – wir beraten Sie, welche Architektur für Ihr konkretes Vorhaben die richtige ist.
Weiteres Material:
