Multi-tenancy in Laravel.

Wat is multi-tenancy?

Multi-tenancy betekent dat meerdere klanten (tenants) dezelfde applicatie delen, maar elk hun eigen afgeschermde omgeving ervaren. Denk aan een projectmanagement-tool waarbij bedrijf A en bedrijf B dezelfde software gebruiken, maar elkaars data nooit zien.

Het is de basis van vrijwel elk SaaS-platform. In plaats van voor elke klant een aparte installatie te draaien, deel je de code, de infrastructuur en vaak ook de database. Dat bespaart kosten en vereenvoudigt het beheer — maar het stelt hoge eisen aan je architectuur.

De drie strategieen

Er zijn drie gangbare manieren om multi-tenancy te implementeren. Elke strategie maakt een andere afweging tussen isolatie, complexiteit en kosten.

1. Enkele database met scoping

De eenvoudigste aanpak: alle klanten delen dezelfde database. Elke tabel bevat een verwijzing naar de juiste klant en je applicatie filtert automatisch op de actieve organisatie. Dit zorgt ervoor dat klant A nooit de gegevens van klant B kan zien.

Voordelen:

• Minimale infrastructuurkosten — een database voor alle tenants
• Eenvoudige setup en migraties
• Cross-tenant rapportages en analyses zijn simpel
• Nieuwe tenants aanmaken is instant

Nadelen:

• Risico op data-lekkage als je scoping niet waterdicht is
• Een zware query van tenant A kan tenant B vertragen
• Lastig om per tenant een eigen backup/restore te doen
• Database kan een bottleneck worden bij veel tenants

Geschikt voor: Startups en MVPs, applicaties met veel kleine tenants, situaties waar snelheid van ontwikkeling prioriteit heeft boven maximale isolatie.

Multi-tenancy is de basis van elk SaaS-platform. De architectuurkeuze die je nu maakt, bepaalt hoe makkelijk je over twee jaar kunt schalen.

2. Database per tenant

Elke tenant krijgt een eigen database. Je applicatie wisselt bij elk verzoek naar de juiste database-connectie op basis van de geidentificeerde tenant. Dit geeft sterke isolatie terwijl je nog steeds een enkele codebase deelt.

Voordelen:

• Volledige data-isolatie — geen kans op cross-tenant lekkage
• Per-tenant backup en restore is triviaal
• Performance van de ene tenant beinvloedt de andere niet
• Je kunt per tenant de database schalen of optimaliseren
• Voldoet makkelijker aan strenge compliance-eisen (AVG, ISO)

Nadelen:

• Hogere infrastructuurkosten — elke tenant is een database
• Migraties moeten op alle databases worden uitgevoerd
• Cross-tenant queries zijn complex of onmogelijk
• Operationele overhead groeit lineair met het aantal tenants

Geschikt voor: Enterprise SaaS waar klanten hoge isolatie-eisen stellen, sectoren met strenge compliance-vereisten, platforms met een beperkt aantal grotere klanten.

3. Schema per tenant (PostgreSQL)

Een middenweg die alleen beschikbaar is met PostgreSQL. Alle tenants delen dezelfde database-server, maar elke tenant krijgt een eigen schema (namespace). Dit combineert de isolatievoordelen van aparte databases met de operationele eenvoud van een gedeelde server.

Voordelen:

• Goede data-isolatie op schema-niveau
• Lagere kosten dan database-per-tenant
• Per-tenant backup is mogelijk via schema dumps
• Migraties zijn eenvoudiger dan bij aparte databases

Nadelen:

• Alleen beschikbaar met PostgreSQL
• Schema-management wordt complex bij honderden tenants
• Gedeelde database-resources — een crash raakt iedereen
• Minder gangbaar in het Laravel-ecosysteem

Geschikt voor: Middelgrote SaaS-platforms met tientallen tot honderden tenants, teams die al met PostgreSQL werken, situaties waar je goede isolatie wilt zonder de overhead van aparte databases.

Multi-tenancy in Laravel: de praktijk

Laravel biedt een volwassen ecosysteem voor multi-tenancy. De architectuur wordt ingebouwd in het framework, niet erop geplakt. Dat betekent dat tenant-isolatie door de hele applicatie heen consistent werkt.

Tenant-identificatie

De eerste stap is altijd: hoe identificeer je de tenant bij een binnenkomend verzoek? De meest voorkomende methoden:

• Subdomain — elke klant krijgt een eigen adres, zoals klant-a.jouwapp.nl; de meest gebruikte aanpak voor SaaS
• Pad-prefix — klanten worden onderscheiden via het webadres; simpeler maar minder overzichtelijk
• Eigen domein — grotere klanten loggen in via hun eigen webadres; een premium optie
• Header/API key — voor API-gebaseerde applicaties

Alle methoden worden ondersteund en zijn eenvoudig te combineren, zodat je bijvoorbeeld subdomeinen gebruikt voor standaardklanten en eigen domeinen aanbiedt aan enterprise accounts.

Wat er automatisch wordt afgehandeld

Een goede multi-tenancy implementatie handelt meer af dan alleen database-switching. Denk aan:

• Cache-isolatie — Cache keys worden automatisch geprefixed per tenant
• Queue-isolatie — Jobs worden uitgevoerd in de context van de juiste tenant
• File storage — Uploads worden per tenant gescheiden
• Configuratie — Tenant-specifieke instellingen (SMTP, API keys, branding)

Begin simpel. Een gedeelde database met goede scoping is voor 90% van de startende SaaS-platforms meer dan voldoende. Complexiteit kun je altijd later toevoegen.

Veelgemaakte fouten

In de praktijk zien we regelmatig dezelfde fouten bij multi-tenant implementaties:

Te vroeg kiezen voor database-per-tenant. Het klinkt als de veiligste optie, maar de operationele overhead is significant. Als je begint met 5 klanten is het beheersbaar. Bij 500 klanten run je 500 databases met 500 migratie-runs bij elke update. Start met scoping tenzij je een concrete reden hebt om dat niet te doen.

Geen tenant-context in achtergrondprocessen. Queued jobs, scheduled tasks en event listeners draaien buiten de HTTP-request context. Als je niet expliciet de tenant-context meestuurt, opereren ze zonder scoping — met alle risico's van dien.

Hardcoded verwijzingen naar gedeelde resources. Een admin-panel dat alle tenants moet kunnen zien, een systeem-level cron job, gedeelde lookup-tabellen — niet alles hoort bij een tenant. Plan vooraf welke delen van je applicatie tenant-scoped zijn en welke niet.

Geen testing met meerdere tenants. Schrijf tests die expliciet wisselen tussen tenants en verifieer dat data-isolatie waterdicht is. Een bug in je scoping is een datalek.

Een bug in je tenant-scoping is geen softwarefout; het is een datalek. Test altijd expliciet met meerdere klanten en controleer dat data-isolatie waterdicht is.

De juiste keuze maken

De keuze voor een multi-tenancy strategie is een van de belangrijkste architectuurbeslissingen voor je SaaS-platform. Het is lastig om later van strategie te wisselen zonder significante refactoring.

Ons advies: begin met de eenvoudigste strategie die aan je huidige eisen voldoet. Voor de meeste startende SaaS-platformen is dat single-database met scoping. Groei je naar enterprise klanten met strenge isolatie-eisen? Dan kun je voor die specifieke klanten upgraden naar database-per-tenant, terwijl kleinere klanten op het gedeelde model blijven.

Het mooie van Laravel is dat deze hybride aanpak volledig wordt ondersteund. Je hoeft niet alles vooraf te beslissen — maar je moet wel bewust starten met een strategie die ruimte laat om te groeien.