Wat is een multi-tenant applicatie?
Een multi-tenant applicatie is een systeem waarbij meerdere klanten (tenants) gebruikmaken van dezelfde software-instantie, maar elke klant alleen zijn eigen data ziet. De code en infrastructuur zijn gedeeld, de data is strikt gescheiden. Dit is de standaard architectuur achter SaaS-producten zoals Salesforce, Slack en vrijwel alle cloudtoepassingen. Het maakt schalen goedkoper: je beheert één applicatie in plaats van een aparte versie per klant.
Een multi-tenant applicatie bedient meerdere klanten vanuit één systeem. Elke klant ziet alleen zijn eigen data, maar de software zelf draait gedeeld.
Wat multi-tenant betekent
In een multi-tenant applicatie zijn alle klanten (tenants) gebruiker van dezelfde software-instantie. De code draait op gedeelde servers, de database is gedeeld, en updates worden voor alle klanten tegelijk uitgerold. Maar elke tenant ziet alleen zijn eigen data.
De scheiding is logisch, niet fysiek. Technisch zitten alle klanten in hetzelfde systeem. Maar de applicatie dwingt af, op database- of applicatieniveau, dat een aanvraag van organisatie A nooit data van organisatie B oplevert. Meer over hoe je die scheiding technisch inricht lees je in het artikel over authenticatie en toegangscontrole in een webapplicatie.
Single-tenant versus multi-tenant
Bij single-tenant heeft elke klant een eigen instantie: aparte server, aparte database, aparte deployment. Dit is eenvoudig te begrijpen en biedt maximale isolatie. Het nadeel is de operationele last: vijftig klanten betekent vijftig aparte systemen om bij te houden, te updaten en te monitoren.
Bij multi-tenant beheert het team één systeem dat werkt voor alle klanten. Updates uitrollen kost één deployment. Nieuwe functionaliteit is direct beschikbaar voor alle klanten. De complexiteit zit in de technische scheiding van data, niet in de operationele complexiteit.
Gegevensisolatie: hoe het werkt
De kritieke vraag bij multi-tenancy is: hoe zorg je dat klanten nooit elkaars data zien? Er zijn drie gangbare aanpakken.
De eerste is een aparte database per tenant. Maximale isolatie, maar operationeel zwaarder. De tweede is een gedeelde database met aparte schema’s per tenant. Iets efficiënter, maar nog altijd complex te beheren. De derde aanpak is één database met een tenant-id op elke rij, waarbij row-level security (RLS) op databaseniveau afdwingt dat queries alleen data van de juiste tenant teruggeven. Dit is de meest schaalbare aanpak en de standaard bij platforms zoals Supabase.
Voordelen voor SaaS-producten
Multi-tenancy is de reden dat SaaS-producten schaalbaar zijn. Je voegt een nieuwe klant toe door een record te aanmaken, niet door een nieuwe server op te zetten. Kosten per klant dalen naarmate het klantenbestand groeit. En je beheert één codebase, één pipeline, één monitoring-stack.
Meer over wat dit betekent voor de opbouw van een SaaS-applicatie lees je in het artikel over wanneer maatwerk software zinvoller is dan een standaardpakket.
Wanneer je het wilt bouwen
Multi-tenancy bouw je wanneer je een applicatie wil schalen naar meerdere klanten zonder dat de beheerlast lineair meegroeit. Dit geldt voor SaaS-producten die je commercieel verkoopt, maar ook voor interne platforms waarbij meerdere afdelingen of bedrijfsonderdelen als aparte tenants worden behandeld.
Het vereist meer technische voorbereiding dan een single-tenant applicatie. Gegevensisolatie moet van het begin af aan correct zijn: het achteraf inbouwen is kostbaar en foutgevoelig. Begin dus met de juiste architectuur, ook al start je met één klant.
Onze tip: implementeer row-level security in je database van dag één, ook als je begint met één klant. Het kost weinig moeite bij de start en bespaart een volledige refactor zodra je een tweede klant aansluit.
Veelgestelde vragen
Wat is het verschil tussen single-tenant en multi-tenant?
Bij single-tenant heeft elke klant een eigen instantie van de applicatie: eigen server, eigen database, eigen deployment. Bij multi-tenant draaien alle klanten op dezelfde instantie, maar ziet elke klant alleen zijn eigen data. Single-tenant biedt meer isolatie en is makkelijker aan te passen per klant, maar is duurder te beheren. Multi-tenant is schaalbaar en kostenefficiënt, maar vereist zorgvuldige technische scheiding van data.
Hoe zorg je dat klanten elkaars data niet zien in een multi-tenant systeem?
Gegevensisolatie in een multi-tenant applicatie kan op drie niveaus: op databaseniveau (elke tenant heeft een eigen database), op schemaniveau (elke tenant heeft een eigen schema in dezelfde database) of op rijniveau (alle tenants zitten in dezelfde tabellen maar elke rij heeft een tenant-id). Row-level security (RLS) op databaseniveau, zoals Supabase dat ondersteunt, is een betrouwbare aanpak waarbij de database zelf afdwingt dat queries nooit data van een andere tenant teruggeven.
Wanneer kies je voor multi-tenant en wanneer voor single-tenant?
Kies multi-tenant als je een SaaS-product bouwt dat je wil schalen naar veel klanten met een beheersbare operationele last. Kies single-tenant als klanten strikte dataresidentie-eisen hebben, als klantspecifieke aanpassingen aan de code nodig zijn of als het om een kleine groep klanten gaat waarbij operationele eenvoud zwaarder weegt dan schaalbaarheid. Veel enterprise-klanten in gereguleerde sectoren eisen single-tenant vanwege compliance.