Multi-Tenancy in SaaS-Webapps: So baust du eine Anwendung für viele Kunden gleichzeitig

Du hast die Idee für ein SaaS, vielleicht sogar schon die ersten zehn Kunden – und dann fragt der erste: "Können wir das mit unserem Logo und auf unserer Subdomain bekommen?" Der zweite will andere Felder im Formular. Der dritte fragt, ob seine Daten "wirklich getrennt" von den anderen liegen.

In diesem Moment merkst du: Du baust kein Produkt mehr, du baust eine Multi-Tenancy SaaS-Architektur. Und die Entscheidungen, die du jetzt triffst, kannst du in zwei Jahren nur unter Schmerzen rückgängig machen. Wir bauen in Hannover seit Jahren mandantenfähige Webapps und sehen immer wieder dieselben Fehler, die später teure Migrationen erzwingen.

Was Multi-Tenancy SaaS wirklich bedeutet

Multi-Tenancy heißt: Eine Codebase, eine laufende Anwendung, viele voneinander getrennte Kunden. Jeder Mandant – das kann eine Firma, ein Team oder ein Einzelnutzer sein – sieht nur seine eigenen Daten, sein eigenes Branding und nur die Features, für die er bezahlt.

Das Gegenteil davon ist Single-Tenancy: Pro Kunde eine eigene Installation, eigene Datenbank, eigener Server. Das ist der klassische Custom-Software-Ansatz und vom Wartungsaufwand der Tod jedes SaaS-Geschäftsmodells.

Multi-Tenancy ist deshalb das Fundament, nicht ein Feature. Sie entscheidet:

• ob du 10 oder 10.000 Kunden bedienen kannst, ohne dass dein Team explodiert
• wie schnell du neue Funktionen ausrollen kannst (eine Codebase = ein Deploy)
• wie hoch deine Cloud-Rechnung am Monatsende wirklich ist
• wie sicher du beim DSGVO-Audit dastehst

Wer den Unterschied zwischen interner Webapp und echtem SaaS noch nicht kennt, sollte vorab unseren Webapp-Guide durchlesen – Multi-Tenancy ist genau die Schwelle, an der die eine zur anderen wird.

Die drei Multi-Tenancy-Modelle: Shared DB, Separate Schema, Separate DB

Es gibt drei etablierte Modelle, wie du Mandantendaten technisch trennst. Keines ist objektiv "richtig" – aber zwei davon sind in 90 % der Fälle falsch für dein konkretes Projekt. Hier ist die ehrliche Übersicht.

Modell 1: Shared Database, Shared Schema (mit tenant_id-Spalte)

Alle Kunden teilen sich eine Datenbank und eine Tabellenstruktur. Jede Zeile in jeder Tabelle hat eine tenant_id-Spalte, jede Query filtert daraufhin.

SELECT * FROM invoices WHERE tenant_id = $1 AND status = 'unpaid';

Vorteile:

• Günstigste Variante (eine DB, ein Backup, ein Index)
• Einfachste Migrationen (eine ALTER TABLE für alle Kunden gleichzeitig)
• Optimal bei vielen kleinen Kunden (1.000+ Tarif-Accounts)

Nachteile:

• Höchstes Risiko für Datenlecks bei Programmierfehlern
• Noisy-Neighbor-Effekt (ein Großkunde langsamt alle anderen aus)
• Schwierige individuelle Backups oder Restores ("Bitte stell unsere Daten von letzter Woche wieder her")

Modell 2: Shared Database, Separate Schema

Eine Datenbank, aber pro Kunde ein eigenes Schema (in PostgreSQL: tenant_a.invoices, tenant_b.invoices). Die Anwendung schaltet pro Request das Schema um.

Vorteile:

• Logische Trennung auf DB-Ebene (Backups pro Kunde möglich)
• Schemamigrationen lassen sich pro Kunde ausrollen (sanfte Updates)
• Guter Mittelweg bei mittlerer Kundenanzahl (10–500 Kunden)

Nachteile:

• Schemamigrationen über alle Kunden brauchen ein durchdachtes Migrationstool
• PostgreSQL-Connection-Pools werden komplexer
• Höhere Wartung als reines Shared

Modell 3: Separate Database pro Kunde

Jeder Mandant bekommt seine eigene physische (oder zumindest logisch komplett getrennte) Datenbank.

Vorteile:

• Maximale Datenisolierung (Hardlock auf DB-Ebene)
• Individuelle Performance-SLAs möglich
• Compliance-Killer: einfach zu erklären beim DSGVO-Audit oder bei ISO-27001-Zertifizierung

Nachteile:

• Höchste Infrastrukturkosten
• Schemamigrationen über 200 DBs sind ein Auftrag für sich
• Erfordert ausgereiftes Tooling (Provisioning, Monitoring, Backups)

Datenisolierung ist nicht verhandelbar – ein Leak ist das Ende

Egal welches Modell du wählst: Wenn Kunde A die Daten von Kunde B sieht, ist dein SaaS tot. Nicht "in Schwierigkeiten" – tot. Niemand wird je wieder bezahlen, niemand wird je wieder Daten hochladen, und beim ersten Audit landest du in der Bußgeldspirale.

Die häufigste Ursache von Tenant-Leaks ist nicht ein gehackter Server, sondern ein vergessenes WHERE tenant_id = ? in einer einzigen Query. Genau einmal vergessen reicht.

So bauen wir die Isolierung wirklich wasserdicht:

1. Row-Level-Security (RLS) auf DB-Ebene aktivieren (PostgreSQL kann das nativ). Die DB selbst weigert sich dann, fremde Daten auszuliefern – auch wenn der Code Mist baut
2. ORM-Mittelschicht mit globalem Tenant-Filter, der nicht umgangen werden kann (z. B. Prisma-Middleware, TypeORM-Subscriber)
3. Audit-Logging jeder Cross-Tenant-Anfrage – Admin-Funktionen, die DBs übergreifend lesen, müssen explizit markiert sein
4. Penetration-Tests mindestens jährlich, mit dem expliziten Ziel "Versuche aus Tenant A heraus auf Tenant B zuzugreifen"

Subdomain-Routing: Wie kunde1.deinsaas.de technisch funktioniert

Branding pro Mandant ist im B2B-SaaS Pflicht. Niemand will seinen Mitarbeitern erklären, warum sie sich auf mygenericsaas.com/login?company=acme einloggen sollen. Der Standard ist daher Tenant-Subdomains: acme.deinsaas.de, kunde2.deinsaas.de.

Technisch funktioniert das in drei Schritten:

Schritt 1: Wildcard-DNS

Du legst einen DNS-Record an: *.deinsaas.de → Server-IP. Damit zeigen automatisch alle Subdomains auf deinen Server. Bei Cloudflare, Vercel oder Netlify ist das ein Klick. Wichtig: Auch dein TLS-Zertifikat muss Wildcard-fähig sein (Let's Encrypt unterstützt das via DNS-Challenge).

Schritt 2: Subdomain in der Server-Middleware lesen

In Nuxt 3 (und genauso in Next.js) liest du die Subdomain in einer Server-Middleware, bevor gerendert wird:

// server/middleware/tenant.ts (Nuxt 3)
export default defineEventHandler(async (event) => {
  const host = getRequestHeader(event, 'host') || ''
  const subdomain = host.split('.')[0]

  if (subdomain === 'www' || subdomain === 'app') return

  const tenant = await db.tenant.findUnique({ where: { slug: subdomain } })
  if (!tenant) throw createError({ statusCode: 404, statusMessage: 'Tenant not found' })

  event.context.tenant = tenant
})

Der event.context.tenant ist jetzt in jeder API-Route, jeder Server-Komponente und jedem useAsyncData-Aufruf verfügbar – komplett serverseitig, kein Client-Code involviert.

Schritt 3: Branding und Theme dynamisch laden

Das Tenant-Objekt enthält Logo-URL, Primärfarbe, Schriftart. Im Layout liest du sie aus, setzt CSS-Custom-Properties und renderst die Marke des Kunden. Wer hier mehr Tiefe will, findet im Artikel UX Design für Webapps und Kundenbindung die UX-Seite des Themas.

Preismodelle und Feature-Flags: Tarifstufen technisch sauber abbilden

Free, Starter, Business, Enterprise – jeder SaaS hat Tarifstufen. Die kritische Frage: Wie verhinderst du, dass der Free-User per Browser-Devtools das Enterprise-Feature freischaltet?

Die Antwort heißt Feature-Flags auf Server-Seite – niemals nur im Frontend.

Plan-basierte Feature-Flags

Jeder Tenant hat einen plan-Wert in der DB. Jede geschützte Funktion prüft:

function canAccess(tenant: Tenant, feature: string): boolean {
  return PLAN_MATRIX[tenant.plan].includes(feature)
}

Das Mapping ist eine simple Konstante. Kein Hardcoding pro Route.

Limit-basierte Flags

Manche Features sind nicht binär, sondern haben Limits ("max. 5 Projekte im Starter-Tarif"). Diese Limits gehören in eine zentrale enforceLimit()-Funktion, die vor jedem Schreibvorgang aufgerufen wird – nicht erst im Frontend versteckt.

A/B-Tests mit Feature-Flag-Tools

Für Experimentier-Flags (nicht Plan-basiert, sondern "rollout an 10 % der Kunden") empfehlen wir Tools wie Unleash, PostHog oder GrowthBook – self-hosted oder gemanagt. Wichtig: Die Auflösung des Flags muss serverseitig und per Tenant geschehen, nicht per User – sonst sehen verschiedene Mitarbeiter desselben Kunden unterschiedliche Features.

Wenn dein bestehendes System hier hart an die Wand fährt (alte Excel-Lösungen, hartkodierte PHP-Schalter), ist meist eine Strangler-Fig-Migration weg von Legacy-Systemen der richtige Weg.

DSGVO bei Multi-Tenancy SaaS: AVV, Datentrennung, Löschkonzepte

In Deutschland kannst du den schönsten SaaS bauen – ohne saubere DSGVO-Umsetzung kommst du nicht in den Mittelstand. Wir sehen das in Hannover bei jedem Pitch beim Konzern-Einkauf: Erst Compliance, dann Funktionen.

Die wichtigsten Pflichten:

Auftragsverarbeitungsvertrag (AVV) pro Kunde

Da deine Kunden personenbezogene Daten ihrer Endnutzer durch dich verarbeiten lassen, bist du Auftragsverarbeiter im Sinne der DSGVO. Pro Kunde brauchst du einen unterschriebenen AVV. Best Practice: AVV-Modul ins Onboarding integrieren – kein Login, bis er digital signiert ist.

Technisch nachweisbare Datenisolierung

Beim Audit reicht "wir haben eine tenant_id-Spalte" nicht. Du musst zeigen:

• Welche technischen Maßnahmen Cross-Tenant-Zugriffe verhindern (RLS, Middleware, Tests)
• Welche organisatorischen Maßnahmen Mitarbeiter-Zugriffe regeln (Vier-Augen-Prinzip bei Datenbank-Operationen)
• Wie Backups isoliert sind (Backup von Tenant A darf bei Wiederherstellung nicht Tenant B treffen)

Löschkonzept und Recht auf Vergessen

Wenn ein Endnutzer (nicht der Kunde, sondern dessen Mitarbeiter) Löschung verlangt, musst du:

1. Identifizieren können, in welchem Tenant der Datensatz liegt
2. Vollständig löschen (auch in Backups, je nach Aufbewahrungsfrist)
3. Den Vorgang dokumentiert dem Kunden zurückmelden

Plane das Löschkonzept vor dem ersten Kunden – nachträgliches "echtes" Löschen aus 50 Tenant-Datenbanken ist die Hölle.

Verzeichnis von Verarbeitungstätigkeiten (VVT)

Pflicht bei mehr als 250 Mitarbeitern oder bei regelmäßiger Verarbeitung sensibler Daten – also praktisch immer. Dein VVT muss alle Datenflüsse zwischen Mandanten dokumentieren.

Skalierung und Architektur-Blick nach vorn

Multi-Tenancy ist nicht das Ende, sondern der Anfang. Sobald die ersten 100 Kunden laufen, kommen Themen wie regionale Datenresidenz (EU-Kunden in Frankfurt, US-Kunden in Virginia), horizontale DB-Skalierung und tenant-spezifische Caches dazu. Wer früh weiß, wie eine skalierbare Web-Architektur für Zukunftssicherheit aussieht, baut von Anfang an die richtigen Stellschrauben ein.

Auch die Frage Custom Code oder Baukasten stellt sich neu: Bauchasten-Frameworks wie Bubble oder Retool haben oft schwache Tenant-Isolation. Tiefer dazu im Cluster Custom Code vs. Baukasten-Webapps.

Fazit: Multi-Tenancy SaaS ist eine Architekturentscheidung, keine Programmierübung

Wer Multi-Tenancy SaaS richtig baut, gewinnt drei Dinge: Skalierbarkeit, Margen und Compliance. Wer es falsch baut, verliert in genau der Reihenfolge: erst Performance, dann Vertrauen, dann den Vertrag.

Die Kurzfassung:

• Starte mit Shared Database + tenant_id und Row-Level-Security – außer du hast hochsensible Branchen-Daten
• Plane Subdomain-Routing als Server-Middleware, nicht als Frontend-Hack
• Baue Feature-Flags serverseitig, niemals nur per CSS-Klasse
• Setze DSGVO vom ersten Tag an um, nicht "wenn der erste Konzernkunde fragt"
• Halte die Architektur einfach genug, dass dein zukünftiges Team in zwei Jahren noch durchblickt

Wir bauen in Hannover SaaS-Webapps, die genau auf diese Multi-Tenancy-Prinzipien aufbauen – und begleiten dich von der Architekturentscheidung bis zum ersten zahlenden Mandanten.

Cagri Ersöz

Multi-Tenancy-Architektur-Workshop für dein SaaS

Du planst ein SaaS oder hängst beim ersten zehnten Kunden in Skalierungsproblemen fest? Wir analysieren in einem 2-Stunden-Workshop dein Modell, zeigen dir Risiken in der Datenisolierung und liefern eine konkrete Architekturempfehlung – inklusive DSGVO-Setup.

Architektur-Workshop sichern