Tenant-isolatie: shared vs database-per-tenant.

De kernvraag

Eén database voor alle tenants, of elke tenant een eigen database? Het klinkt als een technisch detail, maar het is een van de meest fundamentele architectuurbeslissingen die je maakt bij het bouwen van een SaaS-platform. De keuze raakt alles: je kostenstructuur, de performance-karakteristieken van je applicatie, je compliance-verhaal richting klanten en auditors, en de operationele complexiteit van je dagelijks beheer.

Er is geen universeel juist antwoord. Beide modellen hebben legitieme use cases en serieuze trade-offs. Wat we in de praktijk zien is dat teams te vaak kiezen op basis van onderbuikgevoel of technische voorkeur, zonder de consequenties volledig te doorgronden. Dit artikel biedt een concreet beslisframework waarmee je die keuze onderbouwd kunt maken.

Shared database: single-database multi-tenancy

Hoe het werkt

Bij een shared database delen alle tenants dezelfde database-instantie. Elke tabel bevat een verwijzing naar de klant waar een record bij hoort. In Laravel wordt elke query automatisch gefilterd op de actieve tenant. De gebruiker merkt niets van het gedeelde karakter — voor hen voelt de applicatie volledig afgeschermd.

De applicatie identificeert de tenant bij elk binnenkomend request (via subdomain, header of pad) en past vervolgens de filtering toe op alle database-operaties. Dit patroon is lichtgewicht, bewezen in de praktijk en wordt breed ondersteund binnen het Laravel-ecosysteem.

Voordelen

• Lage operationele drempel — Eén database betekent één backup-strategie, één monitoring-setup en één set migraties die alle tenants raakt. Nieuwe tenants aanmaken is een kwestie van een rij toevoegen.
• Kostenefficient — Je betaalt voor één database-instantie, ongeacht het aantal tenants. Bij honderden of duizenden kleine klanten scheelt dat significant.
• Eenvoudige deployments — Een migratie draai je één keer en het geldt voor iedereen. Geen scripts die over honderden databases itereren.
• Cross-tenant inzichten — Rapportages, analytics en admin-overzichten zijn triviaal omdat alle data in dezelfde database staat.

Nadelen

• Noisy neighbor — Een tenant die een zware rapportage draait, kan de database vertragen voor alle andere tenants. Je deelt niet alleen de data, je deelt ook de resources.
• Compliance-uitdagingen — Het aantonen van data-isolatie richting auditors is lastiger. De isolatie bestaat puur op applicatieniveau, niet op infrastructuurniveau. Eén bug in je scoping is een datalek dat alle tenants raakt.
• Beperkte per-tenant flexibiliteit — Een individuele tenant backuppen of restoren is complex. Dataverwijdering bij offboarding vereist chirurgische precisie in plaats van het simpelweg droppen van een database.
• Schaalplafond — Op een gegeven moment bereik je de limieten van een enkele database-instantie. Horizontaal schalen van een shared database is significant complexer dan het spreiden van aparte databases.

Database-per-tenant

Hoe het werkt

Elke tenant krijgt een eigen database. Bij elk binnenkomend request identificeert de applicatie de tenant en schakelt dynamisch naar de bijbehorende database-connectie. De codebase blijft gedeeld — alleen de data is fysiek gescheiden. In Laravel configureer je dit via dynamische database-connections die at runtime worden opgebouwd op basis van de tenant-configuratie.

Een centrale database (vaak de "landlord" database) bevat de tenant-registratie en connectie-gegevens. De tenant-databases bevatten uitsluitend tenant-specifieke data. Dit model geeft harde grenzen tussen tenants op infrastructuurniveau.

Voordelen

• Volledige data-isolatie — Geen enkel scenario waarin data van tenant A zichtbaar wordt voor tenant B. De scheiding is fysiek, niet logisch. Auditors en compliance-officers waarderen dit enorm.
• Geen noisy neighbor — Een zware query van de ene tenant heeft geen impact op de performance van andere tenants. Elke database opereert onafhankelijk.
• Per-tenant operations — Backup, restore, dataverwijdering en zelfs schaling kun je per tenant afhandelen. Een klant wil een restore van gisteren? Dump terugzetten, klaar. Een klant vertrekt? Database droppen.
• Compliance-proof — Bij ISO 27001-audits, AVG-verzoeken of sectorspecifieke regelgeving (financieel, zorg, overheid) is het aantoonbaar maken van data-isolatie triviaal. De data staat fysiek gescheiden.
• Per-tenant optimalisatie — Je kunt voor een grote enterprise-klant een krachtigere database-server inzetten zonder dat dit je kosten voor kleinere klanten beinvloedt.

Nadelen

• Operationele complexiteit — Elke database-migratie moet op alle tenant-databases worden uitgevoerd. Bij honderd tenants zijn dat honderd migratie-runs die allemaal moeten slagen. Dat vereist robuuste tooling en monitoring.
• Hogere kosten — Meer databases betekent meer resources, meer opslag en vaak hogere licentiekosten. Bij duizenden kleine tenants wordt dit kostenmodel onhoudbaar.
• Connection management — Elke tenant vereist een eigen database-connectie. Bij veel gelijktijdige tenants kan connection pooling een uitdaging worden. Je moet bewust omgaan met connection limits en connection reuse.
• Cross-tenant queries — Een admin-dashboard dat aggregaties over alle tenants toont, vereist queries over meerdere databases. Dat is complex, traag en soms onmogelijk zonder aparte rapportage-infrastructuur.

Data-isolatie is geen feature die je er later bij bouwt. Het is een architectuurbeslissing die je op dag één maakt en waar je jaren mee leeft.

Het beslisframework

In plaats van een abstracte afweging, stel jezelf deze concrete vragen. Het antwoord wijst richting de juiste strategie.

Heb je te maken met strenge compliance-eisen? Denk aan ISO 27001, NEN 7510, sector-specifieke regelgeving of klanten die een ISAE 3402-verklaring eisen. Ga voor database-per-tenant. De tijd die je bespaart bij audits en het aantoonbaar maken van isolatie weegt ruimschoots op tegen de operationele overhead.

Bedien je enterprise klanten? Grote organisaties stellen vrijwel altijd eisen aan data-isolatie, hebben eigen SLA's en verwachten de mogelijkheid van per-tenant backup en restore. Database-per-tenant is hier de standaard.

Verwacht je duizenden kleine tenants? Bij een self-service SaaS-model met grote aantallen kleine klanten is een shared database vrijwel altijd de betere keuze. De kosten- en beheerlast van duizenden individuele databases is niet proportioneel.

Verwerk je data uit de overheid of zorgsector? Database-per-tenant. Geen discussie. De regelgeving in deze sectoren vereist aantoonbare isolatie op infrastructuurniveau. Logische isolatie via scoping wordt in veel gevallen niet geaccepteerd.

Ben je een startup of bouw je een MVP? Start met een shared database. De eenvoud en snelheid van ontwikkeling wegen zwaarder dan theoretische isolatievoordelen. Je kunt later migreren als de behoefte zich concreet voordoet.

De hybride aanpak. In de praktijk zien we steeds vaker een hybride model: een shared database voor het gros van de tenants, gecombineerd met dedicated databases voor enterprise klanten die daar specifiek om vragen. Dit geeft je het beste van beide werelden — lage kosten voor de bulk, maximale isolatie voor de klanten die het nodig hebben. Laravel ondersteunt dit hybride model volledig.

De juiste isolatiestrategie wordt niet bepaald door wat technisch het elegantst is, maar door wat je klanten contractueel en wettelijk van je verwachten.

Conclusie

Tenant-isolatie is geen binaire keuze die je in vijf minuten maakt. Het is een strategische beslissing die je kostenmodel, je compliance-positie en je operationele complexiteit voor jaren bepaalt. Shared database is niet "goedkoop en onveilig" en database-per-tenant is niet "duur maar beter". Beide modellen zijn legitiem, mits bewust gekozen.

Gebruik het beslisframework. Kijk naar je doelmarkt, je compliance-eisen en je verwachte groeipad. Kies de strategie die past bij je huidige realiteit, maar zorg ervoor dat je architectuur ruimte laat om te bewegen. De hybride aanpak — standaard shared, dedicated op verzoek — is voor veel groeiende SaaS-platformen de meest pragmatische route. Begin bewust, documenteer je keuze en bouw de tooling die je nodig hebt om die keuze waar te maken.