5 signalen dat jouw SaaS-product echte multi-tenant architectuur nodig heeft

De meeste SaaS-producten beginnen met een datamodel dat technisch meerdere klanten ondersteunt, maar daar niet voor is ontworpen: één gedeelde database met een aan de zijkant toegevoegde customer_id-kolom. Dat werkt prima, tot het moment dat het niet meer werkt, en dat moment doet zich meestal voor op het slechtst denkbare tijdstip: tijdens een enterprise-verkooptraject.

Het eerste signaal is een prospect die tijdens de inkoopbeoordeling vraagt naar garanties voor data-isolatie. Het tweede is een engineer die een eenmalig script moet schrijven om data te herstellen die tussen tenant-grenzen is gelekt. Het derde is queryprestaties die onvoorspelbaar verslechteren naarmate het datavolume van je grootste klant groeit en invloed begint te hebben op iedereen die dezelfde tabellen deelt.

Het vierde signaal is de behoefte aan configuratie per klant, feature flags, aangepaste velden, verschillend retentiebeleid, en de constatering dat het huidige schema daar nergens netjes plaats voor heeft. Het vijfde is een klant die vraagt om een dedicated omgeving of specifieke compliance-garanties die je architectuur niet netjes kan bieden.

Rijniveau-beveiliging, afgedwongen op databaseniveau in plaats van alleen in applicatiecode, is wat de isolatiekloof daadwerkelijk dicht. Een conventie op applicatieniveau als "altijd filteren op tenant_id" werkt totdat ergens een query dat vergeet, en precies die ene misser is het incident dat eindigt in een beveiligingsreview. Row-level security-policies in Postgres (of het equivalent in jouw database) maken de isolatiegrens iets wat de database afdwingt, zelfs als de applicatiecode een fout bevat.

Isolatie testen moet adversarial zijn, niet alleen functioneel. Het is niet genoeg om te controleren dat tenant A de data van tenant A ziet; je hebt tests nodig die actief proberen tenant A de data van tenant B te laten zien via elk codepad, inclusief achtergrondtaken, cachelagen en zoekindexen, precies de plekken waar isolatiefouten zich daadwerkelijk verstoppen.

De migratie zelf is meer een volgordeprobleem dan een engineeringprobleem. We beginnen meestal met de tabellen met het hoogste risico (die al prestatie- of lekkagesymptomen vertonen), voegen tenant-bewuste indexering en row-level security-policies toe achter een feature flag, valideren tegen productieverkeer in schaduwmodus, en migreren dan tabel voor tabel in plaats van in één release.

Geen van deze signalen betekent dat een volledige herbouw nodig is. Echte multi-tenant architectuur is meestal een incrementele migratie: rijniveau-beveiliging, tenant-bewuste indexering en een duidelijke isolatiegrens, uitgevoerd in fasen achter het product dat je klanten al gebruiken. De kostbare versie is degene die onder druk wordt uitgevoerd, tijdens een deal, in plaats van daarvoor.