Multi-Tenant SaaS mit Laravel: Architektur-Entscheidungen

Multi-Tenancy in Laravel

Wenn du ein SaaS-Produkt baust, musst du früh entscheiden wie du mehrere Kunden (Tenants) in einer Instanz verwaltest. Diese Entscheidung ist schwer rückgängig zu machen.

Die drei Ansätze

Single Database, Shared Tables: Alle Tenants in einer Datenbank, jede Tabelle hat eine tenant_id. Einfach, günstig — aber es braucht konsequente Scoping-Logik überall.

Single Database, Separate Schemas: PostgreSQL-spezifisch. Jeder Tenant bekommt ein eigenes Schema. Gute Balance zwischen Isolation und Kosten.

Separate Databases: Maximale Isolation, einfaches Backup pro Tenant — aber höhere Komplexität und Kosten.

Meine Empfehlung

Für die meisten SaaS-Projekte: Single Database mit tenant_id und dem Paket stancl/tenancy. Konsequentes Global Scoping über alle Models verhindert Datenlecks.

Was ich in der Praxis gelernt habe

Den Tenant-Context früh im Request-Lifecycle setzen. Middleware ist dein Freund. Niemals vergessen Queue-Jobs den richtigen Tenant-Context mitzugeben.