Multi-tenant architectuur betekent dat één draaiende applicatie meerdere klanten bedient, ook wel tenants genoemd, terwijl de gegevens van elke tenant gescheiden blijven. Het is de standaardbasis van SaaS-producten, omdat alle klanten dezelfde code en infrastructuur delen, wat de operationele kosten laag houdt. Het ontwerpwerk zit in het van elkaar isoleren van tenants.
Wat is een tenant
Een tenant is een klantaccount met eigen gebruikers en gegevens, bijvoorbeeld een bedrijf dat jouw product gebruikt. Medewerkers van tenant A mogen nooit gegevens van tenant B zien, ook al gebruiken beiden dezelfde applicatie en vaak dezelfde database.
Hoe verschilt dit van single-tenant
Bij een single-tenant opzet krijgt elke klant een eigen deployment. Dat biedt sterke isolatie en eenvoudige maatwerk per klant, maar verveelvoudigt het werk: elke upgrade, back-up en incident herhaalt zich per klant.
| Multi-tenant | Single-tenant | |
|---|---|---|
| Infrastructuur | Gedeeld | Per klant |
| Operationele kosten per klant | Lager | Hoger |
| Upgrades | Eén keer voor iedereen | Per klant |
| Isolatie | Via ontwerp en toegangsregels | Fysiek |
| Maatwerk | Beperkt, via instellingen | Breed |
| Geschikt voor | Meeste SaaS | Strikte compliance, grote maatwerkopdrachten |
Welke databasemodellen zijn er
Teams kiezen meestal uit een van de drie:
- Gedeelde database, gedeelde tabellen. Elke rij bevat een tenant-ID. Dit is de goedkoopste en eenvoudigste aanpak om te schalen, en het vereist dat elke query correct filtert.
- Gedeelde database, schema per tenant. Elke tenant krijgt een eigen schema. De isolatie is sterker en migraties worden zwaarder naarmate het aantal tenants groeit.
- Database per tenant. De sterkste isolatie en de hoogste kosten, vaak gebruikt voor grote of gereguleerde klanten.
Veel producten beginnen met gedeelde tabellen en verplaatsen grote klanten later naar een eigen database.
Hoe houd je tenants geïsoleerd
Dwing isolatie op meerdere plekken af. Zet de tenant-ID in elke tabel en elk querypad, en voeg besturingselementen op databaseniveau toe zoals row level security, zodat een gemiste filter in de applicatiecode geen data lekt. Test er expliciet op: schrijf tests die proberen de data van een andere tenant te lezen en verwacht dat ze mislukken. Een lek tussen tenants behoort tot de meest schadelijke bugs die een SaaS-product kan hebben.
Wat is het noisy neighbour-probleem
Wanneer tenants resources delen, kan één zware tenant de anderen vertragen. Plan hierop met rate limits, quota's per tenant, achtergrondtaakrijen met eerlijke scheduling en monitoring die de belasting per tenant laat zien. Een zware klant verplaatsen naar dedicated resources is een gangbare oplossing.
Wat betekent dit voor compliance
Gedeelde infrastructuur roept vragen op bij beveiligingsreviews. Grotere klanten vragen vaak waar hun data staat, hoe die is afgeschermd en wie er toegang toe heeft. Beslis vroeg of je regionale hosting kunt aanbieden, zoals EU-dataresidentie, of een dedicated deployment voor klanten die dat vereisen. Dat achteraf inbouwen in een ontwerp dat is gebouwd rond gedeelde tabellen kost veel moeite.
Wat dit betekent voor je engineeringteam
Tenancy is moeilijk te wijzigen zodra er data bestaat, dus de beslissing verdient de tijd van een senior engineer aan het begin. AI-codeeragenten kunnen snel queries genereren en laten een tenant-filter gemakkelijk weg, dus isolatietests en besturingselementen op databaseniveau zijn belangrijker wanneer agenten code schrijven. Zie hoe je AI-gegenereerde code reviewt voor de reviewgewoonten die dit opvangen.
Backendplatforms zoals Supabase bieden row level security die geschikt is voor gedeelde-tabeltenancy. Onze vetting plaatst kandidaten in een echte codebase voor twee sessies van zestig minuten: één zonder AI-tools en één met hun eigen agents. Om seniorcapaciteit toe te voegen aan een SaaS-team, zie backend engineers, vanaf €5.600 per maand voor een fulltime engineer.
Korte antwoorden
Is multi-tenancy hetzelfde als SaaS?
Niet precies. De meeste SaaS-producten gebruiken multi-tenancy omdat het de kosten verlaagt, maar een SaaS-product kan ook een aparte deployment per klant draaien.
Welk multi-tenant databasemodel is het beste?
Gedeelde tabellen met een tenant-ID is het eenvoudigst en goedkoopst. Schema of database per tenant biedt sterkere isolatie tegen hogere kosten.
Hoe voorkom je dat data tussen tenants lekt?
Filter overal op tenant, voeg databasecontroles toe zoals row level security, en schrijf tests die proberen tenantgrenzen te overschrijden.
Kan ik later overstappen van single-tenant naar multi-tenant?
Ja, maar het is een grote wijziging in datamodellen en toegangscontrole, dus beslis hier zo vroeg mogelijk over.
