Multi-tenant vs single-tenant | De juiste SaaS-architectuur kiezen

Elk SaaS-product moet een fundamentele vraag beantwoorden: hoe bedien je meerdere klanten vanuit dezelfde software? Het antwoord is je tenancy-model. Het beïnvloedt kosten, beveiliging, prestaties en hoe snel je kunt leveren. Het vroeg goed doen bespaart je van pijnlijke migraties later.

Definities

Multi-tenant

Eén instantie van de applicatie bedient alle klanten. Iedereen deelt dezelfde servers, dezelfde codebase en vaak dezelfde database. De data van elke klant is logisch geïsoleerd, maar de infrastructuur wordt gedeeld.

Zie het als een flatgebouw. Elke huurder woont in hetzelfde gebouw, deelt de lift en gangen, maar heeft hun eigen afgesloten appartement met hun eigen meubels.

Single-tenant

Elke klant krijgt zijn eigen dedicated instantie van de applicatie. Aparte servers, aparte databases, soms aparte codebases. Niets wordt gedeeld tussen klanten.

Zie het als vrijstaande huizen. Elke huurder heeft zijn eigen gebouw, zijn eigen waterleiding, zijn eigen tuin. Complete isolatie, maar duurder om te onderhouden.

Hoe multi-tenancy werkt

Er zijn drie gangbare benaderingen voor multi-tenant architectuur, elk met verschillende afwegingen.

Model 1: Gedeelde applicatie, gedeelde database

Alle tenants delen een enkele applicatie-instantie en een enkele database. Tenantdata wordt gescheiden met een tenant-identifier (meestal een tenant_id-kolom) op elke tabel.

Architectuur:

• Eén applicatieserver (of cluster) verwerkt alle verzoeken.
• Eén database slaat alle tenantdata op.
• Elke query bevat een WHERE tenant_id = ?-clausule om data tot de juiste tenant te beperken.

Voordelen:

• Laagste infrastructuurkosten. Eén database, één app-deployment.
• Eenvoudigst om te deployen en bij te werken. Push eenmaal, iedereen krijgt de wijziging.
• Gemakkelijk om data te aggregeren over tenants voor analytics en rapportage.

Nadelen:

• Hoogste risico op datalekken als een query het tenantfilter vergeet.
• Eén zware tenant kan de prestaties voor iedereen verslechteren.
• Databasemigraties treffen alle tenants tegelijk.
• Moeilijkst om te voldoen aan dataresidentievereisten.

Dit is de meest gangbare aanpak voor B2B SaaS-producten met een groot aantal kleine tot middelgrote klanten.

Model 2: Gedeelde applicatie, aparte databases

Alle tenants delen dezelfde applicatie-instantie, maar elke tenant krijgt zijn eigen database. De applicatie stuurt query’s naar de juiste database op basis van de geauthenticeerde tenant.

Architectuur:

• Eén applicatieserver (of cluster) verwerkt alle verzoeken.
• Een aparte database per tenant.
• Een routeringslaag koppelt tenantidentiteit aan de juiste databaseverbinding.

Voordelen:

• Sterkere data-isolatie. Geen risico op cross-tenant query’s.
• Makkelijker om aan dataresidentievereisten te voldoen. Je kunt elke database in de vereiste regio van de tenant plaatsen.
• Back-up en herstel per tenant is eenvoudig.
• Zwaar gebruik door één tenant blokkeert geen tabellen voor andere tenants.

Nadelen:

• Meer infrastructuur om te beheren. Honderden tenants betekent honderden databases.
• Schemamigraties moeten op elke database individueel worden toegepast.
• Cross-tenant rapportage vereist het queryen van meerdere databases.
• Hogere kosten dan een volledig gedeeld model.

Dit is een sterke middenweg voor producten die betere isolatie nodig hebben zonder de kosten van volledige single-tenancy.

Model 3: Aparte applicatie, aparte database

Elke tenant krijgt zijn eigen dedicated applicatie-instantie en eigen database. Volledig geïsoleerd. Dit is in feite single-tenancy, maar beheerd door de SaaS-provider in plaats van de klant.

Architectuur:

• Een dedicated applicatie-deployment per tenant.
• Een dedicated database per tenant.
• Een routeringslaag (vaak een load balancer of API gateway) stuurt verkeer naar de juiste instantie.

Voordelen:

• Complete isolatie. Geen gedeelde resources tussen tenants.
• Maximale flexibiliteit voor maatwerk per tenant.
• Prestaties van één tenant beïnvloeden nooit een andere.
• Eenvoudigste compliance-verhaal.

Nadelen:

• Hoogste infrastructuurkosten, met afstand.
• Deploymentcomplexiteit groeit lineair met het aantal tenants.
• Updates moeten naar elke instantie individueel worden uitgerold (of zeer zorgvuldig worden geautomatiseerd).
• Schaalt economisch niet voor grote aantallen kleine tenants.

Dit model is logisch voor enterprise SaaS waar klanten dedicated infrastructuur eisen en bereid zijn een premie te betalen.

Voordelen en nadelen in een oogopslag

Factor	Multi-tenant (gedeelde DB)	Multi-tenant (aparte DB)	Single-tenant
Infrastructuurkosten	Laagst	Medium	Hoogst
Data-isolatie	Logisch (rij-niveau)	Fysiek (database-niveau)	Compleet
Deploymentcomplexiteit	Laag	Medium	Hoog
Updatesnelheid	Direct voor iedereen	Direct app, per-DB migraties	Per-instantie rollout
Maatwerk	Beperkt	Beperkt	Volledig
Compliance	Moeilijker	Gemiddeld	Makkelijkst
Schaalbaarheid (tenantaantal)	Uitstekend	Goed	Slecht
Noisy neighbor-risico	Hoog	Medium	Geen

Data-isolatie en beveiliging

Data-isolatie is de belangrijkste overweging bij elk tenancy-model. Een beveiligingslek waarbij één tenant toegang heeft tot de data van een andere tenant is catastrofaal voor een SaaS-bedrijf. Het kan vertrouwen vernietigen, regelgeving schenden en het bedrijf beëindigen.

Row-level security

In een gedeeld databasemodel is PostgreSQL’s Row-Level Security (RLS) een van de sterkste verdedigingen tegen datalekken. RLS dwingt tenantisolatie af op databaseniveau, niet op applicatieniveau. Zelfs als je applicatiecode een bug heeft die vergeet te filteren op tenant, voorkomt de database zelf cross-tenant toegang.

Zo stel je het in:

-- Schakel RLS in op een tabel
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Maak een beleid dat toegang beperkt tot de huidige tenant
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- Forceer RLS zelfs voor tabeleigenaren
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Stel voor het uitvoeren van elke query de tenantcontext in:

-- Stel in aan het begin van elk verzoek/transactie
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Nu retourneert deze query automatisch alleen de data van de huidige tenant
SELECT * FROM projects;
-- Geen WHERE-clausule nodig. RLS regelt het.

Applicatieniveau-isolatie

Naast databaseniveau-beveiliging moet je applicatie tenantgrenzen afdwingen:

// Middleware die tenantcontext instelt bij elk verzoek
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // Uit JWT, subdomein of header

  if (!tenantId) {
    return res.status(401).json({ error: "Tenant not identified" });
  }

  // Stel tenantcontext in voor de databaseverbinding
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

Verdediging in de diepte is het principe hier. Vertrouw nooit op een enkele laag van isolatie. Combineer applicatieniveau-filtering, databaseniveau-beveiliging en regelmatige beveiligingsaudits.

Prestatieoverwegingen

Uitdagingen van gedeelde database

In een gedeelde database concurreren alle tenants om dezelfde resources. Een tenant die een zwaar rapport draait kan query’s voor iedereen vertragen. Maatregelen zijn onder andere:

• Connection pooling. Gebruik PgBouncer of een vergelijkbare tool om te voorkomen dat één tenant databaseverbindingen uitput.
• Query-timeouts. Stel maximale uitvoeringstijden in zodat een ontspoorde query niet onbeperkt resources kan blokkeren.
• Rate limiting. Dwing per-tenant limieten af op API-verzoeken en databaseoperaties.
• Read replicas. Stuur zware leesoperaties (rapporten, exports) naar een replica zodat ze de primaire database niet beïnvloeden.

Voordelen van aparte databases

Met per-tenant databases is prestatie-isolatie ingebouwd. De zware werklast van één tenant treft alleen hun eigen database. Je kunt ook grotere of kleinere databases inrichten op basis van het plan en gebruik van elke tenant.

De afweging is beheeroverhead. 500 databases monitoren is moeilijker dan er één monitoren. Geautomatiseerde tooling wordt essentieel.

Kostenimplicaties op schaal

Laten we naar wat ruwe cijfers kijken. Stel dat je 100 tenants hebt.

Gedeelde database (multi-tenant):

• 1 applicatiecluster: ~€200/maand
• 1 beheerde PostgreSQL-instantie: ~€100/maand
• Totaal: ~€300/maand (€3 per tenant)

Aparte databases (multi-tenant):

• 1 applicatiecluster: ~€200/maand
• 100 kleine database-instanties: ~€2.000/maand
• Totaal: ~€2.200/maand (€22 per tenant)

Single-tenant:

• 100 applicatie-instanties: ~€5.000/maand
• 100 database-instanties: ~€2.000/maand
• Totaal: ~€7.000/maand (€70 per tenant)

Deze cijfers zijn vereenvoudigd, maar het patroon klopt. Gedeelde infrastructuur is dramatisch goedkoper. Bij 1.000 tenants wordt het verschil nog groter.

Daarom moet prijsstelling aansluiten bij architectuur. Als je €20 per maand rekent en single-tenant infrastructuur draait voor €70 per tenant, verlies je geld op elke klant.

Wanneer multi-tenant kiezen

Multi-tenant architectuur is de juiste keuze wanneer:

• Je B2B SaaS bouwt voor het MKB. Hoog volume, lagere prijspunten en standaard featuresets.
• Kostenefficiëntie belangrijk is. Je moet infrastructuurkosten laag houden ten opzichte van omzet.
• Je snelle, uniforme updates wilt. Deploy eenmaal, alle tenants krijgen de verbetering.
• Je klanten geen dedicated infrastructuur vereisen. De meeste kleine en middelgrote bedrijven geven niet om waar hun data staat, zolang het veilig is.
• Je in de vroege fase zit. Begin multi-tenant. Het is goedkoper en eenvoudiger. Je kunt later altijd single-tenant aanbieden voor enterpriseklanten.

Wanneer single-tenant kiezen

Single-tenant architectuur is logisch wanneer:

• Je verkoopt aan enterprises. Grote organisaties vereisen vaak dedicated infrastructuur als onderdeel van hun inkoopproces.
• Compliance het eist. Sectoren zoals gezondheidszorg (HIPAA), financiën (SOX, PCI-DSS) en overheid hebben strenge data-isolatievereisten.
• Klanten maatwerk nodig hebben. Als elke klant andere configuraties, integraties of zelfs features vereist, geeft single-tenant je de flexibiliteit.
• Je prijspunt het ondersteunt. Als je €5.000 of meer per maand per klant rekent, zijn de infrastructuurkosten makkelijk te rechtvaardigen.
• Dataresidentie een harde eis is. Wanneer data in een specifiek land moet blijven, is aparte infrastructuur per tenant de meest eenvoudige aanpak.

Hybride benaderingen

Je hoeft er niet slechts één te kiezen. Veel succesvolle SaaS-bedrijven gebruiken een hybride model:

• Multi-tenant voor standaardniveaus. Gratis, starter en pro-klanten delen infrastructuur. Dit houdt kosten laag en laat je schalen.
• Single-tenant voor enterprise. Premiumklanten krijgen dedicated instanties met custom SLA’s, compliance-certificeringen en dedicated support.

De applicatiecode is dezelfde. Het deploymentmodel verschilt. Dit vereist goede infrastructuurautomatisering, maar het is een bewezen patroon.

Hoe een hybride model implementeren

1. Bouw de app eerst als multi-tenant. Alle tenantisolatielogica blijft hetzelfde ongeacht het deploymentmodel.
2. Gebruik infrastructure-as-code (Terraform, Pulumi of CDK) om het aanmaken van omgevingen te automatiseren.
3. Creëer een provisioningpipeline die in minuten een nieuwe dedicated omgeving kan opzetten, niet in dagen.
4. Onderhoud een enkele codebase. Dezelfde Docker-image draait in zowel gedeelde als dedicated omgevingen. Configuratie (niet code) bepaalt het gedrag.

Databasestrategieën in detail

De database is waar tenancybeslissingen de meeste impact hebben. Hier zijn drie bewezen strategieën.

Strategie 1: Gedeelde tabellen met tenant_id

Elke tabel heeft een tenant_id-kolom. Alle query’s filteren erop.

CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- Query altijd met tenantcontext
SELECT * FROM projects WHERE tenant_id = $1;

Beste voor: De meeste SaaS-producten. Eenvoudig, kosteneffectief, goed begrepen.

Strategie 2: Schema per tenant

Elke tenant krijgt zijn eigen PostgreSQL-schema binnen een gedeelde database. Tabellen hebben dezelfde structuur, maar data is fysiek gescheiden.

-- Maak een schema voor een nieuwe tenant
CREATE SCHEMA tenant_abc123;

-- Maak tabellen in het schema van de tenant
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Stel het zoekpad in per verzoek
SET search_path TO tenant_abc123, public;

-- Nu zijn query's automatisch beperkt
SELECT * FROM projects;

Beste voor: Producten die sterkere isolatie nodig hebben dan rij-niveau maar de kosten van aparte databases niet willen. Werkt goed tot een paar honderd tenants.

Strategie 3: Aparte databases

Elke tenant krijgt een dedicated PostgreSQL-instantie (of een dedicated database op een gedeelde server).

// Database-verbindingsroutering
class TenantDatabaseRouter {
  private connections: Map<string, DatabasePool> = new Map();

  async getConnection(tenantId: string): Promise<DatabasePool> {
    if (this.connections.has(tenantId)) {
      return this.connections.get(tenantId)!;
    }

    const config = await this.loadTenantDbConfig(tenantId);
    const pool = new DatabasePool({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.user,
      password: config.password,
    });

    this.connections.set(tenantId, pool);
    return pool;
  }

  private async loadTenantDbConfig(tenantId: string): Promise<DbConfig> {
    // Zoek de databaseverbindingsdetails van de tenant op
    // in een centraal configuratie-archief
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Beste voor: Enterprise SaaS met hoogwaardige klanten, strenge compliance-eisen of dataresidentieverplichtingen.

De beslissing nemen

Hier is een eenvoudig beslissingskader:

1. Wat is de grootte van je doelklant? MKB wijst richting multi-tenant. Enterprise wijst richting single-tenant of hybride.
2. Wat is je prijspunt? Onder €100/maand heb je multi-tenant nodig om winstgevend te zijn. Boven €1.000/maand wordt single-tenant haalbaar.
3. Wat zijn de compliance-eisen? Gereguleerde sectoren vereisen vaak sterkere isolatie.
4. Hoeveel tenants verwacht je? Honderden of duizenden tenants hebben gedeelde infrastructuur nodig. Tien tot vijftig grote tenants kunnen werken met dedicated instanties.
5. Wat is de operationele capaciteit van je team? Single-tenant vereist meer DevOps-investering. Multi-tenant is operationeel eenvoudiger.

Als je twijfelt, begin met multi-tenant met een gedeelde database en row-level security. Het is de goedkoopste optie, het is veilig wanneer correct geïmplementeerd, en het houdt je architectuur eenvoudig. Je kunt later altijd een dedicated laag toevoegen voor enterpriseklanten.

De kern

Er is geen universeel correct tenancy-model. De juiste keuze hangt af van je klanten, je prijsstelling, je compliance-eisen en je operationele capaciteiten.

De meeste SaaS-producten moeten multi-tenant starten. Het is goedkoper, eenvoudiger en schaalt goed. Naarmate je de markt opgaat en aan grotere organisaties verkoopt, voeg single-tenant opties toe voor klanten die ze nodig hebben en er dienovereenkomstig voor willen betalen.

De architectuur moet het bedrijf dienen, niet andersom. Bouw voor de klanten die je vandaag hebt, en ontwerp met voldoende flexibiliteit om de klanten te bedienen die je morgen wilt.

---

Hulp nodig bij het kiezen van de juiste architectuur voor je SaaS-product? We hebben multi-tenant en single-tenant systemen gebouwd in diverse sectoren. Laten we de beste aanpak voor je project bepalen.