Multi-tenant SaaS-datamodelopties voor een no-code backend

Het probleem: tenants gescheiden houden zonder alles te vertragen

Multi-tenancy betekent dat één softwareproduct veel klanten (tenants) bedient, en elke tenant mag alleen zijn eigen data zien. Het lastige is dit consequent te doen: niet alleen op één scherm, maar over elke API-aanroep, beheerderspaneel, export en achtergrondtaak.

Je datamodel beïnvloedt het dagelijkse werk meer dan veel teams verwachten. Het bepaalt permissies, rapportage, query-snelheid naarmate je groeit, en hoe risicovol een “kleine” bug kan zijn. Eén gemist filter kan data lekken. Te agressieve isolatie maakt rapportage onhandig.

Er zijn drie gebruikelijke manieren om een multi-tenant SaaS-datamodel te structureren:

• Eén database waar elke tabel een tenant_id bevat
• Aparte schemas per tenant binnen één database
• Aparte databases per tenant

Zelfs als je visueel bouwt in een no-code backend, gelden dezelfde afwegingen. Tools zoals AppMaster genereren echte backend-code en databasestructuren vanuit je ontwerp, dus vroege modelkeuzes zijn snel zichtbaar in productiegedrag en performance.

Stel je een helpdesktool voor. Als elke ticketrij tenant_id heeft, is het makkelijk om “alle open tickets” op te vragen, maar je moet tenant-checks overal afdwingen. Als elke tenant zijn eigen schema of database heeft, is isolatie standaard sterker, maar cross-tenant rapportage (zoals “gemiddelde sluitingstijd over alle klanten”) vergt meer werk.

Het doel is scheiding die je kunt vertrouwen zonder frictie toe te voegen aan rapportage, support en groei.

Snel kiezen: 4 vragen die het antwoord versmallen

Begin niet met database-theorie. Begin met hoe het product gebruikt wordt en wat je wekelijks nodig hebt om te opereren.

Vier vragen die het antwoord meestal duidelijk maken

1. Hoe gevoelig zijn de gegevens en sta je onder strikte regels? Zorg, financiën en strikte klantcontracten duwen je vaak richting sterkere isolatie (apart schema of aparte database). Het kan risico's verminderen en audits makkelijker maken.

2. Heb je vaak cross-tenant rapportage nodig? Als je regelmatig “alle klanten” metrics nodig hebt (gebruik, omzet, prestaties), is één database met een tenant_id meestal het eenvoudigst. Aparte databases maken dit lastiger omdat je veel plekken moet opvragen en resultaten samenvoegen.

3. Hoe verschillend zullen tenants van elkaar zijn? Als tenants aangepaste velden, workflows of unieke integraties nodig hebben, kunnen aparte schemas of databases de kans verkleinen dat wijzigingen doorsijpelen. Als de meeste tenants dezelfde structuur delen, blijft tenant_id schoon.

4. Wat kan je team realistisch beheren? Meer isolatie betekent meestal meer werk: meer backups, meer migraties, meer bewegende delen en meer plekken waar fouten zich kunnen verschuilen.

Een praktische aanpak is je top twee keuzes te prototypen en vervolgens de echte pijnpunten te testen: permissieregels, rapportagequeries en hoe veranderingen uitrollen naarmate het model evolueert.

Aanpak 1: één database met tenant_id op elke rij

Dit is de meest voorkomende opzet: alle klanten delen dezelfde tabellen en elk tenant-eigendom record draagt een tenant_id. Operationeel is het simpel omdat je één database en één set migraties hebt.

De regel is streng: als een rij bij een tenant hoort, moet die tenant_id bevatten en elke query moet er op filteren. Tenant-eigendomtabellen bevatten typisch users, roles, projecten, tickets, facturen, berichten, bestandsmetadata en join-tabellen die tenant-data verbinden.

Om lekken te verkleinen, behandel tenant_id als niet-onderhandelbaar:

• Maak tenant_id verplicht (NOT NULL) op tenant-eigendomtabellen
• Voeg indexen toe die beginnen met tenant_id (bijvoorbeeld tenant_id, created_at)
• Laat uniciteitsregels tenant_id bevatten (zoals unieke e-mail per tenant)
• Geef tenant_id mee door elke API- en businessflow, niet alleen UI-formulieren
• Dwing het af in de backend, niet alleen in client-side filters

In PostgreSQL kunnen row-level security policies een sterk vangnet toevoegen, vooral als queries dynamisch worden gegenereerd.

Referentie-data valt meestal in één van twee bakken: gedeelde tabellen (zoals countries) zonder tenant_id, en tenant-gescopeerde catalogi (zoals custom tags of pipelines) met tenant_id.

Als je bouwt met AppMaster, voorkomt een eenvoudige gewoonte de meeste incidenten: zet tenant_id van de geauthenticeerde gebruiker voordat je iets creëert of leest in je Business Process-logica, en houd dat patroon consistent.

Impact op permissies: wat verandert per aanpak

Permissies zijn waar multi-tenancy slaagt of faalt. De data-indeling die je kiest verandert hoe je users opslaat, hoe je queries scope't en hoe je “oops”-momenten in adminschermen voorkomt.

Bij één database en tenant_id gebruiken teams vaak één gedeelde Users-tabel en koppelen elke gebruiker aan een tenant en één of meer rollen. De grote regel blijft: elke read en write moet tenant-scope bevatten, zelfs voor “kleine” tabellen zoals instellingen, tags of logs.

Bij aparte schemas hou je vaak een gedeelde identitylaag (login, wachtwoord, MFA) op één plek, terwijl tenant-data in een schema per tenant leeft. Permissies worden deels een routingprobleem: de app moet queries op het juiste schema richten voordat businesslogic draait.

Bij aparte databases is isolatie het sterkst, maar verschuift permissielogica naar infrastructuur: de juiste databaseverbinding kiezen, credentials beheren en “globale” staff-accounts afhandelen.

Over alle drie aanpakken heen verminderen enkele patronen consistent cross-tenant risico:

• Zet tenant_id in de sessie of auth-tokenclaims en behandel het als verplicht.
• Centraliseer tenant-checks op één plek (middleware of een gedeeld Business Process), niet verspreid over endpoints.
• Toon tenant-context duidelijk in admintools en vereis een expliciete tenant-wissel.
• Gebruik impersonatie voor support met een auditlog.

In AppMaster betekent dit meestal dat je tenant-context opslaat direct na authenticatie en hergebruikt in API-endpoints en Business Processes zodat elke query gescoped blijft. Een supportmedewerker zou orders alleen moeten zien nadat de app tenant-context heeft gezet, niet omdat de UI toevallig juist filterde.

Rapportage en performance met een tenant_id-model

Bij de tenant_id single-database aanpak is rapportage doorgaans eenvoudig. Globale dashboards (MRR, aanmeldingen, gebruik) kunnen één query draaien over iedereen, en tenant-niveau rapporten zijn dezelfde query met een filter.

De afweging is performance na verloop van tijd. Naarmate tabellen groeien, kan één drukke tenant een noisy neighbor worden door meer rijen te creëren, meer writes te triggeren en veelvoorkomende queries te vertragen als de database te veel moet scannen.

Indexeren houdt dit model gezond. De meeste tenant-gescopeerde reads moeten een index kunnen gebruiken die begint met tenant_id, zodat de database direct naar die tenant-slice kan springen.

Een goed uitgangspunt:

• Voeg samengestelde indexen toe waarbij tenant_id de eerste kolom is (bijvoorbeeld tenant_id + created_at, tenant_id + status, tenant_id + user_id)
• Houd echt globale indexen alleen wanneer je cross-tenant queries nodig hebt
• Let op joins en filters die tenant_id “vergeten”, wat trage scans veroorzaakt

Retentie en deletes hebben ook een plan nodig omdat de geschiedenis van één tenant tabellen voor iedereen kan opblazen. Als tenants verschillende retentiebeleid hebben, overweeg soft deletes plus geplande archivering per tenant, of het verplaatsen van oude rijen naar een archieftabel die op tenant_id geordend is.

Aanpak 2: aparte schemas per tenant

Bij aparte schemas gebruik je nog steeds één PostgreSQL-database, maar krijgt elke tenant zijn eigen schema (bijvoorbeeld tenant_42). Tabellen binnen dat schema horen alleen bij die tenant. Het voelt als het geven van een “mini-database” aan elke klant, zonder de overhead van het draaien van veel databases.

Een veelvoorkomend patroon houdt globale services in een gedeeld schema en tenant-data in tenant-schemas. De scheiding gaat meestal over wat gedeeld moet worden tussen alle klanten versus wat nooit gemengd mag worden.

Typische verdeling:

• Gedeeld schema: tenants-tabel, plannen, facturatiegegevens, feature flags, audit-instellingen
• Tenant-schema: business-tabellen zoals orders, tickets, voorraad, projecten, custom fields
• Beide kanten (afhankelijk van product): users en rollen, vooral als gebruikers meerdere tenants kunnen benaderen

Dit model vermindert het risico op cross-tenant joins omdat tabellen in verschillende namespaces leven. Het kan ook het gemakkelijker maken om één tenant te back-uppen of te herstellen door op één schema te richten.

Wat teams vaak verrast, zijn migraties. Als je een nieuwe tabel of kolom toevoegt, moet je de wijziging op elk tenant-schema toepassen. Met 10 tenants is dat beheersbaar. Met 1.000 heb je processen nodig: schema-versies bijhouden, migraties in batches uitvoeren en veilig falen zodat één kapotte tenant de rest niet blokkeert.

Gedeelde services zoals auth en billing leven meestal buiten tenant-schemas. Een praktisch patroon is gedeelde auth (één user-tabel met een tenant-membership-tabel) en gedeelde facturatie (Stripe customer IDs, facturen), terwijl tenant-schemas tenant-eigendom business-data opslaan.

Als je AppMaster gebruikt, plan vroeg hoe Data Designer-modellen mappen naar gedeelde versus tenant-schemas, en houd globale services stabiel zodat tenant-schemas kunnen evolueren zonder login of betalingen te breken.

Rapportage en performance met aparte schemas

Aparte schemas geven standaard sterkere scheiding dan puur tenant_id omdat tabellen fysiek verschillend zijn en permissies per schema ingesteld kunnen worden.

Rapportage is uitstekend wanneer de meeste rapporten per tenant zijn. Queries blijven simpel omdat je uit één tenant-tabel leest zonder constant te moeten filteren. Dit model ondersteunt ook “speciale” tenants die extra tabellen of custom kolommen nodig hebben zonder iedereen te belasten.

Aggregate rapportage over alle tenants is waar schemas beginnen te wringen. Je hebt ofwel een rapportagelaag die meerdere schemas kan opvragen, of je onderhoudt gedeelde samenvattingstabellen in een common schema.

Gangbare patronen:

• Per-tenant dashboards die alleen queryen in dat tenant-schema
• Een centraal analytics-schema met nightly rollups uit elk tenant-schema
• Exportjobs die tenant-data kopiëren naar een warehouse-vriendelijk formaat

Performance is meestal goed voor tenant-niveau workloads. Indexen zijn kleiner per tenant en zware writes in één schema beïnvloeden anderen minder snel. De afweging is operationele overhead: het provisionen van een nieuwe tenant betekent het aanmaken van een schema, het draaien van migraties en het op elkaar houden van alle schemas als het model verandert.

Schemas zijn geschikt wanneer je strengere isolatie wilt zonder de kosten van veel databases, of wanneer je aanpassingen per tenant verwacht.

Aanpak 3: aparte database per tenant

Bij een aparte database per tenant krijgt elke klant zijn eigen database (of zijn eigen database op dezelfde server). Dit is de meest geïsoleerde optie: als de data van één tenant beschadigd of verkeerd geconfigureerd raakt, is de kans veel kleiner dat het andere tenants raakt.

Het past goed bij gereguleerde omgevingen (zorg, finance, overheid) of enterprise-klanten die harde scheiding, aangepaste retentieregels of dedicated prestatie verwachten.

Onboarding wordt een provisioning-workflow. Als een nieuwe tenant zich aanmeldt, moet je systeem een database aanmaken of klonen, het basis-schema toepassen (tabellen, indexen, constraints), credentials veilig aanmaken en bewaren, en API-verzoeken naar de juiste database routeren.

Als je met AppMaster bouwt, is de kernkeuze waar je de tenant-directory houdt (een centraal overzicht van tenant naar databaseverbinding) en hoe je garandeert dat elk verzoek de juiste verbinding gebruikt.

Upgrades en migraties zijn de belangrijkste afweging. Een schema-wijziging is niet langer “eenmalig uitvoeren”, het is “voor elke tenant uitvoeren”. Dat voegt operationeel werk en risico toe, dus teams versieschema's en draaien migraties vaak als gecontroleerde jobs die voortgang per tenant bijhouden.

Het voordeel is controle. Je kunt grote tenants eerst migreren, performance observeren en veranderingen geleidelijk uitrollen.

Rapportage en performance met aparte databases

Aparte databases zijn het eenvoudigst te redeneren. Per ongeluk cross-tenant reads komen veel minder voor, en een permissiefout raakt meestal maar één tenant.

Performance is ook een kracht. Zware queries, grote imports of een runaway-rapport in Tenant A vertragen Tenant B niet. Dit beschermt sterk tegen noisy neighbors en maakt het mogelijk resources per tenant te tunen.

De afweging zit in rapportage. Globale analytics over alle tenants wordt het lastigst omdat data fysiek gesplitst is. Patronen die in de praktijk werken zijn onder meer het kopiëren van sleutelgebeurtenissen of tabellen naar een centraal reporting-database, het verzenden van events naar een warehouse-achtige dataset, per-tenant rapporten draaien en resultaten aggregeren (wanneer tenant-aantal klein is) en productmetrics gescheiden houden van klantdata.

Operationele kosten zijn de andere grote factor. Meer databases betekent meer backups, upgrades, monitoring en incident response. Je kunt ook sneller tegen connection-limits aanlopen omdat elke tenant mogelijk een eigen connection pool nodig heeft.

Veelgemaakte fouten die datalekken of later pijn veroorzaken

De meeste multi-tenant problemen zijn geen “grote ontwerp”-fouten. Het zijn kleine weglatingen die uitgroeien tot beveiligingsbugs, rommelige rapportage en dure cleanup. Multi-tenancy werkt als tenant-scheiding een gewoonte is, niet een feature die je er later bij plakt.

Een veelvoorkomend lek is het vergeten van het tenant-veld op één tabel, vooral join-tabellen zoals user_roles, invoice_items of tags. Alles lijkt goed totdat een rapport of zoekopdracht via die tabel join't en rijen van een andere tenant terughaalt.

Een ander veelvoorkomend probleem zijn admin-dashboards die tenant-filtering omzeilen. Het begint vaak als “alleen voor support” en wordt dan hergebruikt. No-code tools veranderen hier niets aan het risico: elke query, business process en endpoint die tenant-data leest, heeft dezelfde tenant-scope nodig.

IDs kunnen je ook pijn doen. Als je mensvriendelijke ID's deelt over tenants (zoals order_number = 1001) en aanneemt dat ze globaal uniek zijn, zullen supporttools en integraties records mengen. Houd tenant-geschaalde identificatoren apart van interne primaire sleutels en voeg tenant-context toe bij opzoekingen.

Tot slot onderschatten teams migraties en backups naarmate ze groeien. Wat makkelijk is met 10 tenants kan traag en riskant zijn met 1.000.

Snelle checks die de meeste pijn voorkomen:

• Maak tenant-eigendom expliciet op elke tabel, inclusief join-tabellen.
• Gebruik één tenant-scoping patroon en hergebruik het overal.
• Zorg dat rapporten en exports niet kunnen draaien zonder tenant-scope (tenzij ze echt globaal zijn).
• Vermijd tenant-ambiguë ID's in API's en supporttools.
• Oefen restore- en migratiestappen vroeg, niet na groei.

Voorbeeld: een supportmedewerker zoekt naar “invoice 1001” en haalt de verkeerde tenant op omdat de lookup tenant-scope oversloeg. Het is een kleine bug met grote impact.

Een snelle checklist voordat je je commit

Voer een paar tests uit voordat je een multi-tenant SaaS-datamodel vastlegt. Het doel is datalekken vroeg te vinden en te bevestigen dat je keuze nog werkt als tabellen groot worden.

Snelle checks die je in een dag kunt doen

• Data isolation proof: maak twee tenants (A en B), voeg vergelijkbare records toe en verifieer dat elke read en update gescoord is op de actieve tenant. Vertrouw niet alleen op UI-filters.
• Permission break test: log in als een Tenant A-gebruiker en probeer een Tenant B-record te openen, bewerken of verwijderen door alleen het record-ID te veranderen. Als iets lukt, beschouw het als een release-blocker.
• Write-path safety: bevestig dat nieuwe records altijd de juiste tenant-waarde krijgen (of in het juiste schema/database terechtkomen), zelfs wanneer ze gecreëerd worden via achtergrondtaken, imports of automatiseringen.
• Reporting trial: bevestig dat je tenant-only rapportage en “all tenants” rapportage (voor intern personeel) kunt doen, met duidelijke regels over wie de globale view mag zien.
• Performance check: voeg nu een indexstrategie toe (vooral voor (tenant_id, created_at) en andere veelgebruikte filters) en meet opzettelijk één trage query zodat je weet hoe “slecht” eruitziet.

Om de rapportagetest concreet te maken, kies twee vragen die je nodig zult hebben (één tenant-gescoord, één globaal) en draai ze tegen sample-data.

-- Tenant-only: laatste 30 dagen, één tenant
SELECT count(*)
FROM tickets
WHERE tenant_id = :tenant_id
  AND created_at >= now() - interval '30 days';

-- Global (admin): vergelijk tenants
SELECT tenant_id, count(*)
FROM tickets
WHERE created_at >= now() - interval '30 days'
GROUP BY tenant_id;

Als je prototypet in AppMaster, bouw deze checks in je Business Process-flows (read, write, delete) en seed twee tenants in de Data Designer. Wanneer deze tests slagen met realistische datavolumes, kun je met vertrouwen committen.

Voorbeeldscenario: van eerste klanten naar opschalen

Een bedrijf van 20 personen lanceert een klantportaal voor zijn klanten: facturen, tickets en een eenvoudig dashboard. Ze verwachten 10 tenants in de eerste maand, met de ambitie naar 1.000 binnen een jaar.

Vroeg is het eenvoudigste model meestal één database waarin elke tabel met klantdata een tenant_id bevat. Het is snel te bouwen, makkelijk te rapporteren en voorkomt gedupliceerde setup.

Bij 10 tenants is het grootste risico niet performance maar permissies. Eén gemist filter (bijvoorbeeld een “lijst facturen” query die tenant_id vergeet) kan data lekken. Het team moet tenant-checks afdwingen op één consistente plek (gedeelde businesslogic of herbruikbare API-patronen) en tenant-scope als niet-onderhandelbaar behandelen.

Als ze van 10 naar 1.000 tenants groeien, veranderen de behoeften. Rapportage wordt zwaarder, support vraagt om “exporteer alles voor deze tenant” en een paar grote tenants domineren het verkeer en vertragen gedeelde tabellen.

Een praktisch upgradepad ziet er vaak zo uit:

1. Houd dezelfde applicatielogica en permissieregels, maar verplaats high-volume tenants naar aparte schemas.
2. Voor de grootste tenants (of nalevingsklanten) verplaats je ze naar aparte databases.
3. Houd een gedeelde rapportagelaag die uit alle tenants leest en plan zware rapporten buiten piekuren.

Kies het eenvoudigste model dat data vandaag veilig scheidt en plan een migratiepad voor het “enkele enorme tenants”-probleem in plaats van er op dag één voor te optimaliseren.

Volgende stappen: kies een model en prototypeer het in een no-code backend

Kies op basis van wat je het eerst wilt beschermen: data-isolatie, operationele eenvoud of tenant-level schaling. Vertrouwen komt door een klein prototype te bouwen en te proberen het te breken met echte permissie- en rapportagegevallen.

Een eenvoudige startgids:

• Als de meeste tenants klein zijn en je eenvoudige cross-tenant rapportage nodig hebt, begin met één database en een tenant_id op elke rij.
• Als je sterkere scheiding nodig hebt maar toch één database wilt beheren, overweeg aparte schemas per tenant.
• Als tenants harde isolatie eisen (compliance, dedicated backups, noisy-neighbor risico), overweeg een aparte database per tenant.

Schrijf voordat je bouwt tenant-grenzen in eenvoudige taal. Definieer rollen (owner, admin, agent, viewer), wat elk kan doen en wat “globaal” betekent (plannen, templates, audit-logs). Bepaal hoe rapportage moet werken: alleen per tenant, of “alle tenants” voor intern personeel.

Als je AppMaster gebruikt, kun je deze patronen snel prototypen: model tabellen in de Data Designer (inclusief tenant_id, unieke constraints en de indexen waarop je queries vertrouwen), en dwing regels af in de Business Process Editor zodat elke read en write tenant-gescoord blijft. Als referentie is AppMaster beschikbaar op appmaster.io.

Een praktisch laatste test: maak twee tenants (A en B), voeg vergelijkbare users en orders toe en voer dezelfde flows voor beide uit. Probeer een rapport te exporteren voor tenant A en geef opzettelijk tenant B-ID's door naar dezelfde endpoints. Je prototype is alleen “veilig genoeg” wanneer die pogingen altijd falen en je belangrijkste rapporten nog steeds snel draaien bij realistische datavolumes.