Ik heb teams zien doorbrengen maanden met debatteren over multi-tenant versus multi-site architectuur, om vervolgens de verkeerde keuze te maken en nog eens zes maanden te besteden aan migratie. Het is een van die beslissingen die abstract lijken totdat je drie sprints verder bent en realiseert dat je content editors per ongeluk kunnen publiceren naar het verkeerde merk, of je deployment pipeline 45 minuten duurt omdat je twaalf sites opnieuw bouwt terwijl er maar één is veranderd.

Dit is geen theoretische vergelijking. Ik heb beide patronen gebouwd -- soms voor dezelfde klant wanneer de eerste keuze niet uitwerkte. Laat me je meenemen door wat werkelijk belangrijk is bij het maken van deze beslissing.

Inhoudsopgave

Multi-Tenant vs Multi-Site Architecture: How to Decide

De Termen Duidelijk Definiëren

Deze termen worden los gebruikt, dus laten we ze goed definiëren.

Multi-Tenant Architectuur

Eén toepassingsinstantie bedient meerdere tenants (merken, klanten, regio's). Ze delen dezelfde codebase, dezelfde database (meestal), en dezelfde deployment. Tenant-isolatie gebeurt op de toepassingslaag -- via middleware, databaseschema's of rij-niveau filtering.

Denk eraan als een appartementengebouw. Iedereen deelt de structuur, leidingen en elektriciteit. Maar elk appartement heeft zijn eigen slot.

Multi-Site Architectuur

Elke site is een aparte toepassingsinstantie met een eigen codebase (of een vertakking van een gedeelde), een eigen database en een eigen deployment pipeline. Ze kunnen een designsysteem of componentenbibliotheek delen, maar worden onafhankelijk ingezet en beheerd.

Dit is meer als een woningwijk. Dezelfde bouwer, vergelijkbare bouwplannen, maar elk huis staat op zijn eigen fundament.

De Hybride Zone

Eerlijk gezegd landen de meeste productiesystemen ergens tussenin. Je zou een multi-tenant CMS kunnen hebben dat inhoud levert aan onafhankelijk ingezette frontends. Of een gedeelde codebase die wordt ingezet als aparte instanties per tenant. De echte vraag is niet "welke van de twee" maar "waar op het spectrum."

Wanneer Multi-Tenant Architectuur Wint

Multi-tenant glans wanneer je sites meer lijken dan ze verschillen.

Sterke Merkconsisteniteitsvereisten

Als je 15 regionale sites voor hetzelfde merk beheert en het ontwerp moet vast blijven, is multi-tenant je vriend. Eén codebase betekent één bron van waarheid voor componenten, lay-outs en interactiepatronen. Wanneer het merkteam de knopstijlen bijwerkt, wordt dit overal uitgerold.

Snelle Schaling naar Nieuwe Tenants

Ik werkte met een franchiseplatform dat wekelijks nieuwe locaties moest starten. Met multi-tenant was het toevoegen van een nieuwe site een database-invoer en een DNS-record. Geen nieuwe infrastructuur, geen nieuwe deployments. Time-to-launch ging van twee weken naar ongeveer 30 minuten.

Gecentraliseerde Content-bewerkingen

Wanneer je een klein content-team hebt dat meerdere eigenschappen beheert, houdt multi-tenant alles op één plek. Editors melden zich aan bij één systeem, schakelen context en beheren inhoud over alle tenants. Geen gedoe met credentials voor twaalf CMS-instanties.

Gezamenlijke Featureontwikkeling

Elke functie die je bouwt komt alle tenants tegelijk ten goede. Bugfixes, prestatieverbeteringen, nieuwe integraties -- deploy eenmaal, baat overal. De ROI op ontwikkelingsinspanning is multiplicatief.

Wanneer Multi-Site Architectuur Wint

Multi-site wint wanneer je sites aanzienlijk moeten verschillen.

Radicaal Verschillende Gebruikerservaringen

Als merk A een e-commercewinkel is en merk B een contentpublicatie, ze in één codebase proppen creëert een chaos. Ik heb multi-tenant codebases gezien waar 60% van de code achter tenant-specifieke voorwaarden zat. Op dat punt heb je niet één toepassing -- je hebt meerdere slechte applicaties die een repo delen.

Verschillende Technologie-vereisten

Misschien heeft de ene site Next.js nodig voor haar dynamische, app-achtige ervaring, terwijl een ander een content-zware site is die perfect is voor Astro. Multi-site laat elke eigenschap het juiste gereedschap gebruiken. We hebben portfolio's gebouwd waar sommige sites op Next.js draaien en anderen op Astro, allemaal pullende van een gedeelde headless CMS.

Onafhankelijke Release-cycli

Wanneer verschillende zakelijke eenheden eigenaar zijn van verschillende sites en deze op hun eigen schema moeten uitrollen, creëert multi-tenant een bottleneck. Een deployment voor de nieuwe functie van tenant A zou geen regressietesten van tenant B tot Z hoeven te vereisen. Multi-site geeft elk team autonomie.

Regelgeving of Data-isolatie

Sommige industrieën vereisen strikte data-isolatie -- niet alleen scheiding op toepassingsniveau, maar fysiek gescheiden databases, mogelijk in verschillende regio's. Healthcare-, financieel- en overheidsprojecten schrijven dit vaak voor. Multi-site maakt naleving eenvoudig omdat isolatie architectonisch is, niet alleen logisch.

Verschillende Prestatieprofielen

Als de ene tenant 10 miljoen maandelijkse bezoeken krijgt en een ander 50.000, betekent gedeelde infrastructuur dat je ofwel over-inrichten voor de kleine tenant of onder-inrichten voor de grote. Aparte deployments laten je elke eigenschap goed dimensioneren.

Multi-Tenant vs Multi-Site Architecture: How to Decide - architecture

Het Besluitvormingsraamwerk

Hier is het raamwerk dat ik werkelijk bij klanten gebruik. Score elke factor voor jouw situatie:

Factor Favoreert Multi-Tenant Favoreert Multi-Site
Site-gelijkenis 80%+ gedeelde UI/functies Minder dan 50% gedeeld
Aantal eigenschappen 10+ sites Minder dan 5 sites
Groeisnelheid Sites toevoegen frequent Stabiel, zelden toevoegend
Teamstructuur Eén centraal team Onafhankelijke teams per site
Content-model Identiek of bijna identiek Aanzienlijk verschillend
Compliance-behoeften Standaard vereisten Strikte data-isolatie
Tech stack Hetzelfde framework overal Verschillende frameworks nodig
Release-cadence Gecoördineerde releases OK Onafhankelijke releases vereist
Aanpassingsdiepte Theme-niveau (kleuren, logo's) Structureel (lay-outs, functies)
Budget Optimaliseren voor efficiëntie Optimaliseren voor flexibiliteit

Als je vooral in één kolom scoort, is de beslissing duidelijk. Als je je precies in het midden splitst, kijk je waarschijnlijk naar een hybride benadering -- en dat is prima.

Architectuurpatronen in de Praktijk

Laat me concreet worden over hoe deze eruit zien in code.

Multi-Tenant met Next.js

Het meest voorkomende patroon dat ik gebruik is middleware-gebaseerde tenant-resolutie:

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

const TENANT_MAP: Record<string, string> = {
  'brand-a.com': 'brand-a',
  'brand-b.com': 'brand-b',
  'brand-c.com': 'brand-c',
};

export function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || '';
  const tenantId = TENANT_MAP[hostname] || 'default';
  
  // Pass tenant context via headers
  const response = NextResponse.next();
  response.headers.set('x-tenant-id', tenantId);
  
  // Rewrite to tenant-specific paths if needed
  const url = request.nextUrl.clone();
  url.pathname = `/${tenantId}${url.pathname}`;
  
  return NextResponse.rewrite(url);
}

Vervolgens trekken je pagina-componenten tenant-specifieke configuratie:

// lib/tenant-config.ts
export async function getTenantConfig(tenantId: string) {
  // Could be from database, CMS, or config files
  return {
    theme: await fetchTheme(tenantId),
    navigation: await fetchNavigation(tenantId),
    features: await fetchFeatureFlags(tenantId),
    locale: await fetchLocaleConfig(tenantId),
  };
}

Dit werkt goed totdat je tenants verschillende paginastructuren, verschillende gegevens-haaltaktieken of verschillende third-party integraties nodig hebben. Dat is wanneer de voorwaardelijke logica begint in te sluipen.

Multi-Site met Gedeelde Pakketten

Voor multi-site gebruik ik een monorepo met gedeelde pakketten:

├── apps/
│   ├── brand-a/          # Next.js app
│   ├── brand-b/          # Astro app  
│   └── brand-c/          # Next.js app
├── packages/
│   ├── ui/               # Shared component library
│   ├── cms-client/       # Shared CMS integration
│   ├── analytics/        # Shared analytics wrapper
│   └── config/           # Shared TypeScript/ESLint config
├── turbo.json
└── package.json

// turbo.json
{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "dist/**"]
    },
    "deploy": {
      "dependsOn": ["build"]
    }
  }
}

Turborepo (of Nx) beheerst de afhankelijkheidsgrafiek zodat je alleen herbouwt wat is veranderd. Merk A krijgt een nieuwe functie? Alleen merk A herbouwt en deplet. Gedeelde UI-pakket wordt bijgewerkt? Alles wat ervan afhangt herbouwt.

De Hybride: Multi-Tenant CMS, Multi-Site Frontend

Dit is eerlijk gezegd mijn favoriete patroon voor de meeste scenario's. Je krijgt gecentraliseerd content-beheer met onafhankelijke frontend-deployments:

┌─────────────────────┐
│   Headless CMS      │
│  (Sanity/Contentful)│
│   Multi-tenant      │
│   content spaces    │
└──────┬──────┬───────┘
       │      │
   ┌───┘      └───┐
   ▼              ▼
┌──────┐    ┌──────┐
│Site A│    │Site B│
│Next.js│   │Astro │
└──────┘    └──────┘

Content-editors krijgen één login en kunnen alle eigenschappen beheren. Ontwikkelaars krijgen onafhankelijke codebases en deployment pipelines. Het is het beste van twee werelden voor teams die het budget ervoor hebben.

CMS-Overwegingen

Je CMS-keuze beperkt aanzienlijk -- of maakt mogelijk -- je architectuurbeslissing.

Multi-Tenant CMS-ondersteuning

CMS Multi-Tenant Model Multi-Site-ondersteuning Prijsimpact
Sanity Datasets per tenant Uitstekend (meerdere datasets in één project) Gratis laag: 2 datasets; betaald vanaf $99/maand
Contentful Spaces per tenant Goed (organisatie-niveau beheer) Elke space telt mee naar plan; $300+/maand
Strapi Enkele DB, gefilterd per tenant Handmatige implementatie nodig Self-hosted, schaal met infrastructuur
Hygraph Omgevingen en stadia Native multi-site content federatie Vanaf $199/maand voor teamplannen
WordPress (headless) WordPress Multisite Volwassen maar ingewikkeld Hostingkosten schalen per site
Payload CMS Collection-level multi-tenancy Groeiende ondersteuning (v3.0+) Self-hosted, open source

Sanity's datasetmodel is bijzonder elegant voor multi-tenant setups. Elke tenant krijgt zijn eigen dataset met zijn eigen schema, maar ze bevinden zich onder één project. Je kunt schemadefinities over datasets delen terwijl je tenant-specifieke aanpassingen toestaat. Op schaal (10+ tenants), houdt dit je content-bewerkingen gezond.

Contentful's benadering van aparte spaces werkt maar wordt snel duur. Elke space op een Team-plan kost echt geld, en je kijkt naar minstens $300/maand voordat je zelfs maar spaces begint toe te voegen.

Content-modellering Implicaties

Met multi-tenant moet je content-model alle tenants accommoderen. Dit betekent meestal:

  • Een tenant of brand veld op elk content-type
  • Tenant-specifieke validatieregels
  • Voorzichtig permissiemodellering zodat editors alleen hun tenant-inhoud zien
  • Gedeelde content-types (zoals "globale instellingen") die tenant-scoping nodig hebben

Met multi-site heeft elke site zijn eigen content-model. Eenvoudiger per site, maar je verliest de mogelijkheid om inhoud over sites heen te delen zonder een extra content-syndica laag.

Prestatie en Schaling

Prestatiekenmerken Multi-Tenant

Het grootste risico met multi-tenant is het "noisy neighbor" probleem. Als tenant A een virale campagne afstormhaalt en verkeer 10x piekt, voelen alle tenants dit. Beperkingsstrategieën:

  • Edge-caching per tenant: Gebruik Vercel's of Cloudflare's edge netwerk met cache-sleutels die de tenant-ID bevatten
  • ISR met tenant-bewuste revalidatie: Valideer alleen de pagina's opnieuw voor de tenant wiens inhoud is veranderd
  • Rate limiting per tenant: Bescherm gedeelde resources tegen elke enkele tenant die ze overweldigt
// next.config.js - ISR with tenant-aware revalidation
export async function generateStaticParams() {
  const tenants = await getAllTenants();
  const paths = [];
  
  for (const tenant of tenants) {
    const pages = await getTenantPages(tenant.id);
    paths.push(...pages.map(page => ({
      tenant: tenant.slug,
      slug: page.slug,
    })));
  }
  
  return paths;
}

Prestatiekenmerken Multi-Site

Elke site schaal onafhankelijk. Dat is het goede nieuws. Het slechte nieuws is dat je N deployment pipelines, N monitoring dashboards en N prestatiebudgetten beheert. Bij 20+ sites wordt operationele overhead de bottleneck, niet applicatieprestatie.

Uit benchmarks die ik in 2025 heb gedraaid, hier is grof wat je kunt verwachten op Vercel:

Metriek Multi-Tenant (1 app, 10 tenants) Multi-Site (10 apps)
Cold start (Edge) 20-50ms 20-50ms per site
Build-tijd 8-15 min (alle tenants) 2-4 min per site
Incrementele build 30-90s 30-90s per site
Geheugen per instantie 256-512MB gedeeld 256-512MB elk
Maandelijkse Vercel-kosten (Pro) ~$20 ~$200 ($20 × 10)

Dat kostenverschil is significant. Multi-tenant op een enkel Vercel Pro-plan op $20/maand versus multi-site needing Enterprise of creatief projectbeheer.

Kostenanalyse

Laten we echt getallen praten voor een portfolio van 10 sites over 12 maanden.

Kostenscenario Multi-Tenant

Regelitem Maandelijkse Kosten Jaarlijkse Kosten
Vercel Pro (1 project) $20 $240
Sanity Team (1 project, 10 datasets) $99 $1.188
Ontwikkeling (initiële opbouw) -- $40.000-60.000
Onderhoud (lopend) $2.000 $24.000
Totaal Jaar 1 -- $65.428-$85.428

Kostenscenario Multi-Site

Regelitem Maandelijkse Kosten Jaarlijkse Kosten
Vercel Pro (10 projects) $200 $2.400
Sanity Team (10 projects) $990 $11.880
Ontwikkeling (initiële opbouw, gedeelde pakketten) -- $50.000-80.000
Onderhoud (lopend, 10 sites) $4.000 $48.000
Totaal Jaar 1 -- $112.280-$142.280

Multi-tenant is ongeveer 40-60% goedkoper, voornamelijk vanwege verminderde onderhoudslas. Maar deze getallen slaan om als multi-tenant complexiteit leidt tot meer bugs, langzamere featureontwikkeling, of een pijnlijke migratie later.

Wil je een nauwkeuriger schatting voor jouw specifieke situatie? We breken architectuurkosten gedetailleerd uiteen tijdens ons discovery-proces.

Migratiestrategieën

Soms start je met de ene benadering en moet je wisselen. Hier is hoe je dit doet zonder alles plat te branden.

Multi-Tenant → Multi-Site

Dit is de meer voorkomende migratie-richting. Tekenen dat je het nodig hebt:

  • Tenant-specifieke code overschrijdt 30% van de codebase
  • Deployments worden geblokkeerd door cross-tenant regressietesting
  • Teams trappen op elkaars veranderingen

De strategie:

  1. Extraheer eerst gedeelde code in pakketten (UI-componenten, hulpprogramma's, CMS-client)
  2. Maak een monorepo-structuur rond de bestaande app
  3. Fork de app voor de meest afwijkende tenant
  4. Verplaats geleidelijk andere tenants naar hun eigen apps
  5. Verwijder tenant-schakellogie uit elke app als deze standalone wordt

Multi-Site → Multi-Tenant

Minder voorkomend maar het gebeurt, meestal wanneer een bedrijf meerdere merken overneemt en de bedrijfsvoering wil consolideren.

  1. Audit alle sites op gedeelde patronen (je vindt meer dan je verwacht)
  2. Bouw de gedeelde componentenbibliotheek uit de beste implementaties
  3. Maak de multi-tenant app met de eenvoudigste site eerst
  4. Migreer sites één tegelijk, valideer pariteit op elke stap
  5. Zet aparte apps buiten bedrijf naarmate tenants live gaan

Beide migraties zijn verstoringen. Begroting 3-6 maanden en aanzienlijke testinginspanning. Dit is precies waarom de eerste beslissing goed nemen belangrijk is -- het is niet alleen een architectuurkeuze, het is een commitment.

Als je voor deze beslissing staat en het wilt doorspreken met iemand die het eerder heeft gedaan, neem contact op.

Veelgestelde Vragen

Wat is het verschil tussen multi-tenant en multi-site architectuur? Multi-tenant gebruikt een enkele toepassingsinstantie om meerdere merken of klanten te bedienen, met tenant-isolatie afgehandeld op de toepassingslaag. Multi-site zet aparte toepassingsinstanties in voor elke site, mogelijk code deelend via een monorepo en componentenbibliotheken. Het sleutelverschil is of je één toepassing of veel applicaties draait.

Kan ik een multi-tenant CMS gebruiken met een multi-site frontend? Absoluut, en het is vaak de beste benadering. Een headless CMS zoals Sanity met meerdere datasets geeft je gecentraliseerd content-beheer, terwijl aparte frontend-deployments elke site onafhankelijkheid geven in termen van technologiekeuzes, deployment-schema's en prestatieschaling. Dit hybride patroon werkt bijzonder goed wanneer je sites inhoudstructuur delen maar verschillende gebruikerservaringen nodig hebben.

Hoe beïnvloedt multi-tenant architectuur SEO? Multi-tenant apps serveren verschillende inhoud gebaseerd op het domein of subdomein, wat zoekmachines prima afhandelen zolang je juiste canonical URLs implementeert, unieke metagegevens per tenant en aparte sitemaps. Het risico is accidentele inhoudsduplicatie over tenants -- zorg ervoor dat je sitemap-generatie en robots.txt tenant-bewust zijn. Vanuit SEO-perspectief geven zoekmachines niet om of je sites een codebase delen; ze geven om de inhoud en opmaak die ze ontvangen.

Is multi-tenant goedkoper dan multi-site? Over het algemeen ja, vaak 40-60% goedkoper in hosting- en onderhoudskosten. Je betaalt voor één deployment, één monitoringsetup en één set infrastructuur. Multi-tenant kan echter duurder worden in ontwikkelingtijd als je tenants aanzienlijk verschillen, omdat de complexiteit van tenant-specifieke logica niet-lineair groeit. Het break-even punt hangt af van hoe gelijk je sites werkelijk zijn.

Welke benadering is het beste voor headless WordPress multisite? WordPress Multisite is inherent multi-tenant -- één WordPress-installatie, meerdere sites. Als je WordPress als headless CMS gebruikt, geeft het Multisite-netwerk je gecentraliseerd content-beheer. Je frontend kan dan ofwel multi-tenant zijn (één Next.js app) of multi-site (aparte apps per WordPress-site). Voor de meeste WordPress-gebaseerde projecten, zou ik het hybride aanbevelen: WordPress Multisite als CMS, aparte frontend-deployments per site.

Hoe handle ik gedeelde authenticatie over een multi-tenant app? Gebruik een gecentraliseerde authenticatieprovider (Auth0, Clerk of NextAuth.js) met tenant-bewust sessionbeheer. Het auth-token moet de tenant-context bevatten, en je middleware moet valideren dat de geverifieerde gebruiker toegang heeft tot de gevraagde tenant. Rij-niveau beveiliging in je database (Supabase en Neon ondersteunen beide dit) voegt een tweede beschermingslaag toe tegen cross-tenant datalekken.

Wat is het maximumaantal tenants dat een multi-tenant app kan afhandelen? Er is geen vaste limiet, maar praktische limieten verschijnen rond build-tijden en operationele complexiteit. Met Next.js ISR op Vercel heb ik multi-tenant apps effectief 50+ tenants zien afhandelen. Voorbij 100 tenants wil je kijken naar on-demand ISR in plaats van alle pagina's voor-genereren, en je zult geavanceerde cachingstrategieën nodig hebben. SaaS-platforms zoals Shopify voeren effectief duizenden tenants uit, maar ze hebben jaren in die infrastructuur geïnvesteerd.

Moet ik een monorepo gebruiken voor multi-site architectuur? Bijna altijd ja. Een monorepo met Turborepo of Nx geeft je de code-delingvoordelen van multi-tenant (gedeelde componenten, hulpprogramma's, configuraties) met de deployment-onafhankelijkheid van multi-site. De sleutel is het houden van gedeelde pakketten goed gedefinieerd en versioned. Zonder monorepo belanden je met copy-paste code over repos die onmiddellijk divergeren en binnen maanden een onderhoudsnachtmerrie wordt.