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 — inmiddels wordt meer dan 86% van alle enterprise software als SaaS geleverd (Bridgenext, 2025). 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 (pakketten als Spatie Laravel Multitenancy bieden wel ondersteuning)
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.
De drie strategieen vergeleken
Een snel beslismodel om de juiste strategie te kiezen op basis van je situatie:
| Criterium | Shared database + scoping | Database per tenant | Schema per tenant |
|---|---|---|---|
| Data-isolatie | Logisch (afhankelijk van scoping) | Fysiek (sterkst) | Logisch + namespace |
| Infrastructuurkosten | Laag (1 database) | Hoog (n databases) | Middel (1 server, n schemas) |
| Migraties bij update | 1 run | n runs (met fan-out) | n runs op 1 server |
| Per-tenant backup | Complex (export per tenant) | Triviaal (database-dump) | Schema-dump |
| Cross-tenant rapportage | Eenvoudig (SQL JOIN) | Complex (data warehouse) | Mogelijk (cross-schema query) |
| Compliance (AVG, ISO27001, NEN7510) | Mogelijk maar bewijslast hoger | Sterkst aantoonbaar | Goed verdedigbaar |
| Aantal tenants waar het schaalt | 1 - tienduizenden | 1 - paar honderd | 1 - paar honderd |
| Database-engine eis | Geen | Geen | PostgreSQL |
De pragmatische vuistregel: kies shared database tenzij een specifieke compliance-eis of klantcontract iets sterkers vereist. Bij twijfel begin je op shared en migreer je grote enterprise-klanten later naar een eigen database — Laravel ondersteunt dit hybride model native.
Wat kost het in de praktijk?
De architectuurkeuze beinvloedt je hostingkosten significant. Een indicatieve vergelijking voor een middelgroot SaaS-platform op AWS (op moment van schrijven, april 2026):
| Scenario | Strategie | Maandelijkse infra-kost (indicatief) | Operationele last |
|---|---|---|---|
| 10 tenants, MVP-fase | Shared DB | ~€80 (RDS db.t4g.medium) | 1 deployment, 1 backup-policy |
| 50 tenants, groei-fase | Shared DB | ~€180 (RDS db.t4g.large) | 1 deployment, monitoring per tenant |
| 50 tenants, enterprise-mix | Hybride (shared + 5x dedicated) | ~€400 (1 large + 5 small) | 6 backup-policies, fan-out migraties |
| 200 tenants, dedicated voor allemaal | Database per tenant | €1.500–3.000+ | 200 migratie-runs per release |
Cijfers zijn ruw en fluctueren met regio (Frankfurt eu-central-1 versus Amsterdam local zone), instance-type en reserved-instance kortingen. De boodschap is vooral: de operationele kosten van database-per-tenant zijn niet lineair. Niet alleen je AWS-rekening groeit; je deployment-pipeline, monitoring-stack en on-call rotatie groeien mee.
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.
Kun je later van strategie wisselen?
Ja, maar het is een ingrijpend traject. Welke kant je opgaat bepaalt hoeveel werk het wordt:
- Shared database → database-per-tenant. Het meest voorkomende migratiepad. Je moet per tenant een nieuwe database aanmaken, data uit de gedeelde database extraheren en herinvoegen, en alle tenant-IDs uit foreign keys verwijderen of negeren. Reken op een onderhoudsvenster, een gevalideerd dry-run-script en sterke rollback-mogelijkheden. In de praktijk: enkele weken werk plus een gefaseerde migratie waarbij eerst nieuwe tenants op het nieuwe model worden geplaatst.
- Database-per-tenant → shared database. Zeldzaam maar voorkomend bij consolidatie. Hier moet je tenant-IDs juist toevoegen aan elk record, en bij ID-collisions (auto-increments) opnieuw nummeren of UUIDs invoeren. Zwaarder dan de andere richting.
- Schema-per-tenant → shared database. Vergelijkbaar met de tweede richting; PostgreSQL biedt wel handige tools (
SET search_path, schema-dumps) om dit gecontroleerd te doen.
De praktijk leert: een hybride model is in 80% van de gevallen de juiste eindstaat. Klein-tot-middelgrote tenants op shared, enkele zwaargewichten op een eigen database. Laravel's connection-resolver maakt deze hybride aanpak transparant voor de applicatiecode.
De juiste keuze maken
De keuze voor een multi-tenancy strategie is een van de belangrijkste architectuurbeslissingen voor je SaaS-platform. Met een wereldwijde multi-tenant SaaS-markt die groeit met 14,7% per jaar tot naar verwachting $13,4 miljard in 2033 (HTF Market Insights, 2025), wordt die keuze alleen maar relevanter. 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.
