Je bouwt een SaaS-applicatie waarbij elke klant zijn eigen omgeving heeft — eigen data, eigen instellingen, eigen gebruikers. Dat is multi-tenancy. Laravel biedt verschillende strategieën om dit te implementeren, elk met eigen trade-offs.

Wat is multi-tenancy?

Een multi-tenant applicatie bedient meerdere klanten (tenants) vanuit één codebase. De tenants zijn geïsoleerd van elkaar: klant A ziet de data van klant B niet. Maar ze draaien op dezelfde servers en hetzelfde code.

Voorbeelden: een SaaS-boekhoudtool, een multi-store platform, een HR-systeem voor meerdere bedrijven.

Strategie 1: Single database, tenant kolom

De eenvoudigste aanpak: alle tenants delen één database, maar elke rij heeft een tenant_id-kolom. Je filtert altijd op tenant_id in je queries.

Voordelen:

Eenvoudig op te zetten
Goedkoop in resources

Nadelen:

Gevaar voor data-lekkage als je ergens de tenant-filter vergeet
Slechte isolatie voor gevoelige data
Backup en restore per tenant is complex

Strategie 2: Aparte database per tenant

Elke tenant krijgt zijn eigen database. Laravel’s database-connectie wordt per request dynamisch ingesteld.

Voordelen:

Sterke data-isolatie
Backup en restore per tenant is eenvoudig
Betere compliance voor gevoelige data

Nadelen:

Duurder in resources bij veel tenants
Database-migraties moeten op alle tenant-databases uitgevoerd worden

Strategie 3: Aparte schema’s per tenant (PostgreSQL)

Met PostgreSQL kan je elk tenant in een eigen schema plaatsen binnen dezelfde database. Goede balans tussen isolatie en resources.

Tenancy for Laravel

De populairste package voor multi-tenancy in Laravel is Tenancy for Laravel (stancl/tenancy). Het ondersteunt zowel single-database als multi-database strategieën, automatische tenant-detectie via subdomain of domein, en automatische database-migraties per tenant.

composer require stancl/tenancy
php artisan tenancy:install

Tenant detectie

Tenants worden typisch gedetecteerd via:

Subdomain: klant1.jouwapp.be
Domein: klant1.be (eigen domein per tenant)
Path: jouwapp.be/klant1 (minder elegant)
Request header: voor API-authenticatie

Aandachtspunten

Queue jobs moeten tenant-aware zijn
Scheduled tasks moeten voor alle tenants draaien
Centrale authenticatie vs. per-tenant authenticatie
Tenant onboarding automatiseren (database aanmaken, migreren, seeden)

Bij Meesy bouwen we SaaS-applicaties en multi-tenant platforms voor klanten die hun software willen aanbieden aan meerdere bedrijven. Architectuurbeslissingen als deze maken we bewust en gedocumenteerd. Neem contact op voor een architectuurgesprek over jouw SaaS-plannen.

Conclusie

Multi-tenant applicaties vereisen een doordachte architecturele aanpak. Kies je strategie op basis van je isolatiebehoeften, het verwachte aantal tenants en je budget voor infrastructure. Tenancy for Laravel maakt de implementatie significant eenvoudiger.