Multi-tenancy in Laravel: zo bouw je een schaalbaar SaaS-platform.

Wat is multi-tenancy?

Stel dat je een softwareplatform bouwt voor HR-teams. Je eerste opdrachtgever is een productiebedrijf met tweehonderd medewerkers. De tweede is een advocatenkantoor. De derde een logistieke dienstverlener. Drie verschillende organisaties, elk met hun eigen gebruikers, hun eigen data en hun eigen processen. Je hebt twee opties: voor elke opdrachtgever een aparte installatie draaien, of één applicatie bouwen die alle drie bedient terwijl hun data strikt gescheiden blijft. Dat tweede is multi-tenancy.

Één applicatie, meerdere opdrachtgevers: hoe werkt dat?

In een multi-tenant systeem is elke opdrachtgever een "tenant". De applicatie herkent bij elk binnenkomend request welke tenant er achter zit, doorgaans via een subdomein (productiebedrijf.jouwplatform.nl), een URL-segment of een JWT-token, en serveert alleen de data van die tenant.

De uitdaging zit hem in de scheiding. Een bug in je tenant-identificatie die ervoor zorgt dat tenant A de data van tenant B kan zien, is niet alleen een technisch probleem. Het is een privacyincident.

Multi-tenancy vs. meerdere installaties: het verschil.

Meerdere installaties zijn eenvoudiger te bouwen en volledig geïsoleerd. Maar ze schalen slecht. Elke nieuwe opdrachtgever betekent een nieuwe server, een nieuwe database, nieuwe deployments en dubbel onderhoud. Bij tien opdrachtgevers is dat al omslachtig. Bij honderd is het onhoudbaar. Multi-tenancy lost dit op door infrastructuur te delen zonder data te vermengen.

De twee hoofdstrategieën in Laravel.

Database-per-tenant: maximale isolatie.

Elke tenant krijgt zijn eigen database. De applicatie verbindt bij elk request dynamisch met de juiste database op basis van de tenant-identificatie.

• Voordelen: maximale data-isolatie, eenvoudige compliance (data van elke tenant staat fysiek apart), eenvoudig te back-uppen per tenant en te exporteren bij opzegging.

• Nadelen: hogere infrastructuurkosten bij veel tenants, complexere migraties (elke database moet bijgewerkt worden) en hogere beheerslast.

Shared database met tenant_id: kostenefficiënt en flexibel.

Alle tenants delen één database. Elke tabel bevat een tenant_id-kolom. De applicatie filtert automatisch alle queries op de actieve tenant.

• Voordelen: lagere infrastructuurkosten, eenvoudigere migraties (één keer uitvoeren), beter voor platformen met veel kleine tenants.

• Nadelen: hogere kans op data-lekken als de tenant-filter niet consequent wordt toegepast, complexere compliance bij strikte datalocatievereisten en potentiële performance-problemen als de database groot wordt.

Hybride aanpak: wanneer dat verstandig is.

Sommige platformen combineren de twee strategieën: gedeelde database voor niet-gevoelige gegevens (configuratie, logging) en aparte databases voor gevoelige data (persoonsgegevens, financiële records). Dat vraagt meer architectuurwerk maar biedt de voordelen van beide werelden.

Multi-tenancy implementeren in Laravel: packages.

Tenancy for Laravel: flexibel en feature-rijk.

Tenancy for Laravel van Arkadiusz Kondas is de meest volwassen open-source oplossing. Het ondersteunt zowel database-per-tenant als shared-database aanpakken, biedt automatische tenant-identificatie via subdomeinen of domeinen en heeft uitgebreide documentatie.

De package gebruikt het concept van "bootstrappers" om de applicatie per request opnieuw te configureren voor de actieve tenant. Cache, queue, storage, database: alles wordt automatisch geswitcht.

Laravel Jetstream en Spark: teams en billing.

Laravel Jetstream biedt een ingebouwde "teams"-structuur die als lightweight multi-tenancy werkt. Dat werkt goed voor platformen waarbij gebruikers tot meerdere teams kunnen behoren en data op team-niveau wordt gescheiden.

Laravel Spark voegt billing toe: abonnementenbeheer via Stripe, direct gekoppeld aan je tenant-structuur. Voor SaaS-platformen waarbij tenants een abonnement afsluiten, is dit een serieuze versneller.

Zelf bouwen vs. package gebruiken

Voor eenvoudige use cases met een shared database en beperkt aantal tenants is een eigen implementatie met global scopes haalbaar. De valkuil: je bouwt langzaam opnieuw wat de packages al goed doen, maar zonder de battle-tested edge cases. Bij complexere vereisten is een package vrijwel altijd de betere keuze.

Valkuilen bij multi-tenancy en hoe je ze vermijdt.

Datalek tussen tenants voorkomen.

Dit is de grootste risico. Een query die per ongeluk geen tenant-filter toepast, retourneert data van alle tenants. In Laravel voorkom je dit door een global scope te gebruiken die automatisch op elk model wordt toegepast, én door dit te testen met integration tests die expliciet controleren dat tenant A geen data van tenant B ziet.

Performance bij shared database.

Als de database groeit, kunnen queries traag worden. Zorg dat elke tabel die tenant-data bevat een index heeft op tenant_id. Overweeg database sharding als het volume extreem groeit. Monitor query-tijden per tenant om prestatieproblemen vroeg te signaleren.

Migraties beheren per tenant.

Bij database-per-tenant moet elke migratie op alle tenant-databases worden uitgevoerd. Tenancy for Laravel heeft hier ingebouwde ondersteuning voor. Bij een zelfgebouwde oplossing is dit een veelgemaakte fout: migraties worden uitgevoerd op de primaire database maar vergeten voor bestaande tenants.