Ich habe Teams beobachtet, die Monate damit verbracht haben, Multi-Tenant- vs. Multi-Site-Architektur zu diskutieren, um sich dann für die falsche Variante zu entscheiden und weitere sechs Monate für die Migration aufzuwenden. Es ist eine dieser Entscheidungen, die abstract wirken, bis man drei Sprints später feststellt, dass deine Content-Editoren versehentlich auf die falsche Marke veröffentlichen können, oder deine Deployment-Pipeline 45 Minuten dauert, weil du zwölf Sites neu erstellst, obwohl sich nur eine geändert hat.

Das ist kein theoretischer Vergleich. Ich habe beide Muster gebaut -- manchmal für denselben Client, wenn die erste Wahl nicht funktioniert hat. Lass mich dir zeigen, was wirklich wichtig ist, wenn du diese Entscheidung triffst.

Inhaltsverzeichnis

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

Die Begriffe klar definieren

Diese Begriffe werden lose verwendet, also lassen Sie uns sie festlegen.

Multi-Tenant-Architektur

Eine Anwendungsinstanz bedient mehrere Mandanten (Marken, Clients, Regionen). Sie teilen dieselbe Codebasis, dieselbe Datenbank (normalerweise) und dieselbe Bereitstellung. Die Mandantenisolation erfolgt auf der Anwendungsebene -- durch Middleware, Datenbankschemas oder Filterung auf Zeilenebene.

Stellen Sie sich das wie ein Apartmentgebäude vor. Alle teilen die Struktur, Rohre und Elektrik. Aber jede Einheit hat sein eigenes Schloss.

Multi-Site-Architektur

Jede Site ist eine separate Anwendungsinstanz mit eigener Codebasis (oder einem Fork einer gemeinsamen), eigener Datenbank und eigener Deployment-Pipeline. Sie könnten ein Design-System oder eine Komponentenbibliothek teilen, aber sie werden unabhängig bereitgestellt und betrieben.

Das ist mehr wie eine Wohnsiedlung. Der gleiche Erbauer, ähnliche Baupläne, aber jedes Haus steht auf seinem eigenen Fundament.

Die Hybrid-Zone

Ehrlich gesagt landen die meisten Produktionssysteme irgendwo dazwischen. Du könntest ein Multi-Tenant-CMS haben, das Inhalte auf unabhängig bereitgestellten Frontends speist. Oder eine gemeinsame Codebasis, die pro Mandant als separate Instanzen bereitgestellt wird. Die eigentliche Frage ist nicht "welche Variante", sondern "wo im Spektrum".

Wann Multi-Tenant-Architektur gewinnt

Multi-Tenant glänzt, wenn deine Sites sich mehr ähneln als unterscheiden.

Starke Anforderungen an Markenkonsistenz

Wenn du 15 regionale Sites für die gleiche Marke verwaltest und das Design gesperrt bleiben muss, ist Multi-Tenant dein bester Freund. Eine Codebasis bedeutet eine einzige Informationsquelle für Komponenten, Layouts und Interaktionsmuster. Wenn das Brand-Team die Button-Stile aktualisiert, wird es überall eingerollt.

Schnelle Skalierung auf neue Mandanten

Ich habe mit einer Franchising-Plattform gearbeitet, die jede Woche neue Standorte starten musste. Mit Multi-Tenant war das Hinzufügen einer neuen Site ein Datenbankeintrag und ein DNS-Record. Keine neue Infrastruktur, keine neuen Bereitstellungen. Die Zeit zum Start ging von zwei Wochen auf etwa 30 Minuten.

Zentralisierte Content-Operationen

Wenn du ein kleines Content-Team hast, das mehrere Properties verwaltet, hält Multi-Tenant alles an einem Ort. Editoren loggen sich in ein System ein, wechseln den Kontext und verwalten Inhalte über alle Mandanten hinweg. Keine Verwaltung von Anmeldedaten für ein Dutzend CMS-Instanzen.

Gemeinsame Feature-Entwicklung

Jedes Feature, das du entwickelst, kommt allen Mandanten gleichzeitig zugute. Bugfixes, Leistungsverbesserungen, neue Integrationen -- einmalig bereitgestellt, überall nutzbar. Der ROI für Entwicklungsaufwand ist multiplikativ.

Wann Multi-Site-Architektur gewinnt

Multi-Site gewinnt, wenn sich deine Sites erheblich unterscheiden müssen.

Radikal unterschiedliche Benutzererfahrungen

Wenn Brand A ein E-Commerce-Storefront ist und Brand B eine Content-Publikation ist, sie in einer Codebasis zu quetschen, ist chaotisch. Ich habe Multi-Tenant-Codebasen gesehen, bei denen 60% des Codes hinter mandantenspezifischen Bedingungen steckte. An diesem Punkt hast du nicht eine Anwendung -- du hast mehrere schlechte mit einem gemeinsamen Repo.

Unterschiedliche Technologieanforderungen

Vielleicht braucht eine Site Next.js für sein dynamisches, app-ähnliches Erlebnis, während eine andere eine inhaltsreiche Site ist, die perfekt für Astro ist. Multi-Site lässt jede Property das richtige Tool verwenden. Wir haben Portfolios gebaut, bei denen einige Sites auf Next.js und andere auf Astro laufen, alle aus einem gemeinsamen Headless-CMS ziehen.

Unabhängige Release-Zyklen

Wenn verschiedene Geschäftsbereiche verschiedene Sites besitzen und sie in ihren eigenen Zeitplänen versenden müssen, schafft Multi-Tenant einen Engpass. Eine Bereitstellung für die neue Funktion von Mandant A sollte nicht erfordern, dass Mandant B bis Z einer Regressionstestung unterzogen wird. Multi-Site gibt jedem Team Autonomie.

Behördliche oder Datenisolation

Einige Branchen erfordern strikte Datenisolation -- nicht nur Anwendungsschicht-Trennung, sondern physisch separate Datenbanken, möglicherweise in verschiedenen Regionen. Gesundheitswesen, Finanz- und Regierungsprojekte schreiben dies häufig vor. Multi-Site macht die Compliance einfach, weil die Isolation architektonisch und nicht nur logisch ist.

Unterschiedliche Leistungsprofile

Wenn ein Mandant 10 Millionen monatliche Besuche erhält und ein anderer 50.000, führt die Infrastruktur-Nutzung dazu, dass du entweder für den kleinen Mandanten über- oder für den großen unter-provisionierst. Separate Bereitstellungen lassen dich jede Property richtig dimensionieren.

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

Das Entscheidungsframework

Hier ist das Framework, das ich tatsächlich mit Clients verwende. Bewerten Sie jeden Faktor für Ihre Situation:

Faktor Bevorzugt Multi-Tenant Bevorzugt Multi-Site
Site-Ähnlichkeit 80%+ gemeinsame UI/Features Weniger als 50% gemeinsam
Anzahl der Properties 10+ Sites Weniger als 5 Sites
Wachstumsrate Häufig neue Sites hinzufügen Stabil, selten neue hinzufügen
Teamstruktur Ein zentrales Team Unabhängige Teams pro Site
Content-Modell Identisch oder nahezu identisch Erheblich unterschiedlich
Compliance-Anforderungen Standard-Anforderungen Strikte Datenisolation
Tech-Stack Überall das gleiche Framework Verschiedene Frameworks nötig
Release-Kadenz Koordinierte Releases OK Unabhängige Releases erforderlich
Anpassungstiefe Theme-Level (Farben, Logos) Strukturell (Layouts, Features)
Budget Effizienz optimieren Flexibilität optimieren

Wenn du hauptsächlich in einer Spalte bewertest, ist die Entscheidung klar. Wenn du aufgeteilt bist, schaust du wahrscheinlich auf einen hybriden Ansatz -- und das ist in Ordnung.

Architekturmuster in der Praxis

Lassen Sie mich konkret werden, wie diese aussehen im Code.

Multi-Tenant mit Next.js

Das häufigste Muster, das ich verwende, ist Middleware-basierte Mandanten-Auflösung:

// 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);
}

Dann ziehen deine Page-Komponenten mandantenspezifische Konfiguration:

// 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),
  };
}

Das funktioniert gut, bis deine Mandanten unterschiedliche Seitenstrukturen, unterschiedliche Datenbeschaffungsstrategien oder unterschiedliche Drittanbieter-Integrationen brauchen. Das ist, wenn die bedingte Logik anfängt zu kriechen.

Multi-Site mit gemeinsamen Paketen

Für Multi-Site verwende ich ein Monorepo mit gemeinsamen Paketen:

├── 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 (oder Nx) verwaltet den Abhängigkeitsgraph, sodass du nur das neu erstellst, was sich geändert hat. Brand A bekommt ein neues Feature? Nur Brand A wird neu erstellt und bereitgestellt. Das UI-Paket wird aktualisiert? Alles, das davon abhängig ist, wird neu erstellt.

Das Hybrid: Multi-Tenant-CMS, Multi-Site-Frontend

Das ist ehrlich gesagt mein Liebingsmuster für die meisten Szenarien. Du bekommst zentralisierte Content-Verwaltung mit unabhängigen Frontend-Bereitstellungen:

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

Content-Editoren erhalten ein Login und können alle Properties verwalten. Entwickler erhalten unabhängige Codebasen und Deployment-Pipelines. Es ist das Beste aus beiden Welten für Teams mit dem Budget dafür.

CMS-Überlegungen

Deine CMS-Wahl beschränkt -- oder ermöglicht -- erheblich deine Architektur-Entscheidung.

Multi-Tenant-CMS-Unterstützung

CMS Multi-Tenant-Modell Multi-Site-Unterstützung Preisauswirkung
Sanity Datasets pro Mandant Ausgezeichnet (mehrere Datasets in einem Projekt) Kostenlos: 2 Datasets; ab $99/Mo
Contentful Spaces pro Mandant Gut (Verwaltung auf Organisationsebene) Jeder Space zählt zum Plan; $300+/Mo
Strapi Einzelne DB, gefiltert nach Mandant Manuelle Implementierung nötig Self-hosted, skaliert mit Infrastruktur
Hygraph Umgebungen und Stages Natürliche Multi-Site-Content-Verbund Ab $199/Mo für Team-Pläne
WordPress (headless) WordPress Multisite Reif aber komplex Hosting-Kosten skalieren pro Site
Payload CMS Sammlungen-Level Multi-Tenancy Wachsende Unterstützung (v3.0+) Self-hosted, Open Source

Sanity's Dataset-Modell ist besonders elegant für Multi-Tenant-Setups. Jeder Mandant bekommt sein eigenes Dataset mit eigenem Schema, aber sie leben unter einem Projekt. Du kannst Schema-Definitionen über Datasets gemeinsam nutzen, während du mandantenspezifische Anpassungen erlaubst. Im großen Maßstab (10+ Mandanten) hält das deine Content-Operationen sinnvoll.

Contentfuls Ansatz mit separaten Spaces funktioniert, wird aber schnell teuer. Jeder Space auf einem Team-Plan kostet echtes Geld, und du schaust auf mindestens $300/Monat, bevor du überhaupt anfängst, Spaces hinzuzufügen.

Content-Modellierungsimplikationen

Mit Multi-Tenant muss dein Content-Modell alle Mandanten unterstützen. Das bedeutet normalerweise:

  • Ein tenant oder brand Feld auf jedem Content-Typ
  • Mandantenspezifische Validierungsregeln
  • Sorgfältige Permission-Modellierung, sodass Editoren nur Inhalte ihres Mandanten sehen
  • Gemeinsame Content-Typen (wie "globale Einstellungen"), die Mandanten-Scoping brauchen

Mit Multi-Site hat jede Site sein eigenes Content-Modell. Einfacher pro-Site, aber du verlierst die Fähigkeit, Inhalte über Sites hinweg zu teilen, ohne eine zusätzliche Content-Verteilungsebene.

Leistung und Skalierung

Multi-Tenant-Leistungsmerkmale

Das größte Risiko mit Multi-Tenant ist das "Lärmender Nachbar"-Problem. Wenn Mandant A eine virale Kampagne läuft und der Verkehr 10x ansteigt, fühlen alle Mandanten es. Mitigierungsstrategien:

  • Edge-Caching pro Mandant: Verwende Vercels oder Cloudflares Edge-Netzwerk mit Cache-Schlüsseln, die den Mandanten-Identifikator enthalten
  • ISR mit mandantengesteuerter Revalidation: Revalidiere nur die Seiten für den Mandanten, dessen Inhalt sich geändert hat
  • Rate-Limiting pro Mandant: Schütze gemeinsame Ressourcen davor, dass ein einzelner Mandant sie überwältigt
// 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;
}

Multi-Site-Leistungsmerkmale

Jede Site skaliert unabhängig. Das ist die gute Nachricht. Die schlechte Nachricht ist, dass du N Deployment-Pipelines, N Monitoring-Dashboards und N Leistungsbudgets verwaltest. Bei 20+ Sites wird der operative Overhead zum Engpass, nicht die Anwendungsleistung.

Aus Benchmarks, die ich 2025 auf Vercel durchgeführt habe, hier ungefähr was zu erwarten ist:

Metrik Multi-Tenant (1 App, 10 Mandanten) Multi-Site (10 Apps)
Cold Start (Edge) 20-50ms 20-50ms pro Site
Build-Zeit 8-15 Min (alle Mandanten) 2-4 Min pro Site
Inkrementeller Build 30-90s 30-90s pro Site
Speicher pro Instanz 256-512MB gemeinsam 256-512MB jede
Monatliche Vercel-Kosten (Pro) ~$20 ~$200 ($20 × 10)

Dieser Kostenunterschied ist erheblich. Multi-Tenant auf einem einzelnen Vercel Pro-Plan bei $20/Monat vs. Multi-Site, das entweder Enterprise oder kreative Projektorganisation braucht.

Kostenanalyse

Lassen Sie uns echte Zahlen für ein Portfolio von 10 Sites über 12 Monate sprechen.

Multi-Tenant-Kostenschätzung

Einzelposten Monatliche Kosten Jährliche Kosten
Vercel Pro (1 Projekt) $20 $240
Sanity Team (1 Projekt, 10 Datasets) $99 $1.188
Entwicklung (ursprünglicher Bau) -- $40.000-60.000
Wartung (laufend) $2.000 $24.000
Total Jahr 1 -- $65.428-$85.428

Multi-Site-Kostenschätzung

Einzelposten Monatliche Kosten Jährliche Kosten
Vercel Pro (10 Projekte) $200 $2.400
Sanity Team (10 Projekte) $990 $11.880
Entwicklung (ursprünglicher Bau, gemeinsame Pakete) -- $50.000-80.000
Wartung (laufend, 10 Sites) $4.000 $48.000
Total Jahr 1 -- $112.280-$142.280

Multi-Tenant ist ungefähr 40-60% billiger, hauptsächlich wegen der reduzierten Wartungslast. Aber diese Zahlen kippen, wenn Multi-Tenant-Komplexität zu mehr Bugs, langsamerer Feature-Entwicklung oder einer schmerzhaften Migration später führt.

Möchtest du eine präzisere Schätzung für deine spezifische Situation? Wir brechen Architektur-Kosten detailliert in unserem Entdeckungsprozess auf.

Migrationsstrategien

Manchmal fängst du mit einem Ansatz an und musst wechseln. Hier ist, wie du es tust, ohne alles in Flammen aufgehen zu lassen.

Multi-Tenant → Multi-Site

Das ist die häufigere Migrationsrichtung. Zeichen, dass du es brauchst:

  • Mandantenspezifischer Code überschreitet 30% der Codebasis
  • Bereitstellungen werden durch Cross-Mandanten-Regressionstestung blockiert
  • Teams treten sich gegenseitig in die Änderungen

Die Strategie:

  1. Extrahiere zuerst gemeinsamen Code in Pakete (UI-Komponenten, Utilities, CMS-Client)
  2. Erstelle eine Monorepo-Struktur um die bestehende App
  3. Forke die App für den am weitesten abweichenden Mandanten
  4. Verschiebe andere Mandanten schrittweise zu ihren eigenen Apps
  5. Lösche Mandanten-Wechsel-Logik aus jeder App, wenn sie unabhängig wird

Multi-Site → Multi-Tenant

Weniger häufig, aber es passiert, normalerweise wenn ein Unternehmen mehrere Marken erwirbt und Operationen konsolidieren will.

  1. Überprüfe alle Sites auf gemeinsame Muster (du findest mehr als erwartet)
  2. Baue die Bibliothek gemeinsamer Komponenten aus den besten Implementierungen
  3. Erstelle die Multi-Tenant-App mit der einfachsten Site zuerst
  4. Migriere Sites eines nach dem anderen, validiere Parität in jedem Schritt
  5. Dekommissioniere einzelne Apps, wenn Mandanten live gehen

Beide Migrationen sind störend. Budgetiere 3-6 Monate und erhebliche Test-Aufwendungen. Das ist genau, warum es wichtig ist, die ursprüngliche Entscheidung richtig zu treffen -- es ist nicht nur eine Architektur-Wahl, es ist eine Verpflichtung.

Wenn du dieser Entscheidung gegenüberstehst und mit jemandem sprechen möchtest, der es schon getan hat, kontaktiere uns.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Multi-Tenant- und Multi-Site-Architektur? Multi-Tenant nutzt eine einzelne Anwendungsinstanz, um mehrere Marken oder Clients zu bedienen, wobei die Mandanten-Isolation auf der Anwendungsebene erfolgt. Multi-Site stellt separate Anwendungsinstanzen pro Site bereit, mit möglicherweise gemeinsamer Code über ein Monorepo und Komponentenbibliotheken. Der Schlüssel-Unterschied ist, ob du eine oder viele Anwendungen betreibst.

Kann ich ein Multi-Tenant-CMS mit einem Multi-Site-Frontend verwenden? Absolut, und es ist oft der beste Ansatz. Ein Headless-CMS wie Sanity mit mehreren Datasets gibt dir zentralisierte Content-Verwaltung, während separate Frontend-Bereitstellungen jeder Site Unabhängigkeit in Bezug auf Technologie-Auswahl, Deployment-Zeitpläne und Performance-Skalierung geben. Dieses Hybrid-Muster funktioniert besonders gut, wenn deine Sites Content-Struktur teilen, aber verschiedene Benutzererfahrungen brauchen.

Wie beeinflusst Multi-Tenant-Architektur die SEO? Multi-Tenant-Apps servieren verschiedene Inhalte basierend auf der Domain oder Subdomain, die Suchmaschinen wunderbar handhaben, solange du korrekte kanonische URLs, einzigartige Metadaten pro Mandant und separate Sitemaps implementierst. Das Risiko ist versehentliche Content-Duplizierung über Mandanten -- stelle sicher, dass deine Sitemap-Generierung und robots.txt mandantengestattet sind. Aus SEO-Perspektive kümmert sich Google nicht, ob deine Sites eine Codebasis teilen; sie kümmern sich um die Inhalte und das Markup, die sie erhalten.

Ist Multi-Tenant billiger als Multi-Site? Allgemein ja, oft 40-60% billiger bei Hosting- und Wartungskosten. Du zahlst für eine Bereitstellung, ein Monitoring-Setup und einen Satz Infrastruktur. Jedoch kann Multi-Tenant teurer in Entwicklungszeit werden, wenn deine Mandanten erheblich abweichen, weil die Komplexität der Verwaltung mandantenspezifischer Logik nicht-linear wächst. Der Break-Even-Punkt hängt davon ab, wie ähnlich deine Sites wirklich sind.

Welcher Ansatz ist besser für Headless WordPress Multisite? WordPress Multisite ist von Natur aus Multi-Tenant -- eine WordPress-Installation, mehrere Sites. Wenn du WordPress als Headless-CMS verwendest, gibt dir das Multisite-Netzwerk zentralisierte Content-Verwaltung. Dein Frontend kann dann entweder Multi-Tenant (eine Next.js-App) oder Multi-Site (separate Apps pro WordPress-Site) sein. Für die meisten WordPress-basierten Projekte würde ich das Hybrid empfehlen: WordPress Multisite als CMS, separate Frontend-Bereitstellungen pro Site.

Wie handhabe ich gemeinsame Authentifizierung über eine Multi-Tenant-App? Verwende einen zentralisierten Authentifizierungs-Provider (Auth0, Clerk oder NextAuth.js) mit mandantengesteuerter Session-Verwaltung. Der Auth-Token sollte den Mandanten-Kontext beinhalten, und deine Middleware sollte validieren, dass der authentifizierte User Zugriff auf den angeforderten Mandanten hat. Row-Level Security in deiner Datenbank (Supabase und Neon unterstützen beide dies) fügt eine zweite Schutzebene gegen Cross-Mandanten-Datenlecks hinzu.

Was ist die maximale Anzahl von Mandanten, die eine Multi-Tenant-App verarbeiten kann? Es gibt keine harte Grenze, aber praktische Grenzen entstehen um Build-Zeiten und operative Komplexität. Mit Next.js ISR auf Vercel habe ich Multi-Tenant-Apps gesehen, die effektiv 50+ Mandanten handhaben. Jenseits von 100 Mandanten wirst du On-Demand ISR statt Pre-Generation aller Seiten betrachten wollen, und du brauchst ausgefeilte Caching-Strategien. SaaS-Plattformen wie Shopify betreiben effektiv Tausende von Mandanten, aber sie haben Jahre in diese Infrastruktur investiert.

Sollte ich ein Monorepo für Multi-Site-Architektur verwenden? Fast immer ja. Ein Monorepo mit Turborepo oder Nx gibt dir die Code-Teilen-Vorteile von Multi-Tenant (gemeinsame Komponenten, Utilities, Konfigurationen) mit der Deployment-Unabhängigkeit von Multi-Site. Der Schlüssel ist es, gemeinsame Pakete gut definiert und versioniert zu halten. Ohne ein Monorepo endest du mit kopiertem Code über Repos, die sich sofort unterscheiden und wird innerhalb von Monaten ein Maintenance-Albtraum.