Multi-Tenant-SaaS-Architektur aufbauen — Schema-Isolation, Auth, Billing

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Multi-Tenant-SaaS-Architektur auf AWS und GCP

Die Antwort in 60 Sekunden

Multi-Tenant-SaaS-Architektur ist ein Design, bei dem eine einzige Anwendungsinstanz und eine gemeinsam genutzte Infrastruktur viele Kundenorganisationen (Tenants) bedienen, während die Daten jedes Tenants logisch oder physisch isoliert bleiben. Die erste und folgenreichste Entscheidung ist das Isolationsmodell; Auth, Billing, Datenresidenz und Observability ergeben sich daraus. Unser SaaS-Entwicklungsteam betreibt alle drei folgenden Modelle in Produktion.

Drei glaubwürdige Isolationsmodelle im Jahr 2026:

1. Gemeinsame Datenbank, gemeinsames Schema, tenant_id-Spalte + Postgres RLS. Standard. Im Betrieb am günstigsten. Unterstützt mehr als 10.000 Tenants auf einem einzigen Aurora- oder Neon-Cluster. Eine spätere Migration zu Schema-per-Tenant ist mühsam, aber möglich.
2. Schema-per-Tenant (separate Postgres-Schemata in derselben Datenbank). Das Enterprise-Upgrade. Nützlich für Gespräche über „logische Isolation" mit Prüfern, ohne die Infrastrukturkosten zu verdoppeln. Unterstützt 200–2.000 Tenants pro Cluster.
3. Database-per-Tenant. Regulierte Workloads, Single-Tenant-Deployments, Kunden, die mehr als 100k USD/Jahr zahlen. Teuer im Betrieb, am einfachsten sauber zu löschen, am einfachsten in regulierten Audits zu rechtfertigen.

Wählen Sie (1) für jedes neue B2B-SaaS. Ergänzen Sie (2) auf der Business-Stufe, sobald Sie Ihren ersten Deal abschließen, bei dem gefragt wird: „Sind meine Daten von anderen Tenants isoliert?" Ergänzen Sie (3) nur für regulierte Branchen oder VIP-Deals über 100k USD ARR.

Drei Isolationsmodelle — Abwägungen

Gemeinsames Schema mit RLS — der richtige Standard

Das Muster „gemeinsames Schema mit RLS" hat sich 2026 zum Senior-Standard für neue B2B-SaaS-Produkte entwickelt. Es funktioniert so:

1. Jede Domänentabelle hat eine Not-Null-Spalte tenant_id uuid references tenants(id), die als Teil jeder gängigen Abfrage indexiert ist.
2. Postgres Row-Level Security ist für jede Domänentabelle aktiviert.
3. Jede Tabelle hat eine RLS-Richtlinie: USING (tenant_id = current_setting('app.tenant_id')::uuid).
4. Jeder Request-Handler führt zu Beginn seiner Transaktion SET LOCAL app.tenant_id = '...' aus, abgeleitet aus dem verifizierten Auth-Token.
5. Die von der Anwendung verwendete Datenbankrolle hat FORCE ROW LEVEL SECURITY gesetzt, sodass selbst die Anwendung die Richtlinie nicht ohne Rollenwechsel umgehen kann.

Das Ergebnis: Ein durchgesickerter SQL-Bug in Ihrer Codebasis kann keine Tenant-Daten preisgeben. Die Datenbank verweigert die Rückgabe von Zeilen anderer Tenants, unabhängig davon, was die Abfrage verlangt. Wir haben auf diese Weise echte Bugs in Kunden-Audits aufgedeckt — Abfragen, die Zeilen anderer Tenants zurückgegeben hätten, durch RLS blockiert, mit einem klaren Fehler in den Logs.

Praxistipps aus unserer Projektarbeit:

• Verwenden Sie einen Connection-Pooler (PgBouncer im Transaction-Pooling-Modus), aber beachten Sie, dass SET LOCAL am Ende der Transaktion zurückgesetzt wird — das ist das korrekte Verhalten.
• Setzen Sie für Hintergrund-Jobs app.tenant_id im Job-Handler; vertrauen Sie niemals allein dem Job-Payload.
• Fügen Sie in der CI einen Smoke-Test hinzu, der absichtlich versucht, die Zeile eines anderen Tenants zu lesen, und sicherstellt, dass 0 Zeilen zurückkommen.
• Zusammengesetzte Indizes sollten mit tenant_id beginnen — z. B. (tenant_id, created_at) — für stabile Abfragepläne.

Schema-per-Tenant — das Enterprise-Upgrade

Wenn Sie anfangen, Enterprise-Deals an die Frage „Liegen meine Daten in derselben Datenbank wie alle anderen?" zu verlieren, ist Schema-per-Tenant der nächste Schritt. Jeder Tenant erhält sein eigenes Postgres-Schema (tenant_a1b2c3) mit dem vollständigen Tabellensatz. Die Anwendung setzt zu Beginn der Transaktion den search_path.

Vorteile gegenüber dem gemeinsamen Schema:

• Echte Isolation auf Schema-Ebene. Ein Bug kann keine Zeilen eines anderen Tenants zurückgeben.
• Einfacheres Backup/Restore pro Tenant (Dump eines einzelnen Schemas).
• Einfacheres Löschen pro Tenant (ein einzelnes DROP SCHEMA CASCADE).
• Prüferfreundliche Antwort: „Jeder Tenant hat ein logisch getrenntes Schema."

Kosten:

• Migrationen müssen über N Schemata parallel und mit ordentlichem Fehler-Handling laufen. Tools: Sqitch, Flyway oder ein eigener Orchestrator.
• Tenant-übergreifende Analyse-Abfragen werden umständlich (Sie können nicht einfach „über alle Tenants SUMMieren"). Lösen Sie das mit einer separaten Analyse-Datenbank, die per CDC gespeist wird.
• Die Größe des Postgres-Katalogs wächst mit N Tenants × N Tabellen. Jenseits von ~2.000 Schemata beginnt sich pg_class-Bloat auf die Planner-Zeit auszuwirken.

Database-per-Tenant — reguliert und isoliert

Für regulierte Branchen (HealthTech, GovTech, Verteidigung, bestimmte Finanz-Workloads) und für Whale-Kunden, die mehr als 100k USD/Jahr zahlen, geben Sie jedem Tenant seine eigene Datenbank. Oft seine eigene VPC und seine eigene Region.

Das ist teuer: 25–150 USD/Monat pro Tenant auf AWS RDS oder Vergleichbarem. Die Rechtfertigung: Das Audit-Argument wird trivial, der Wirkungsradius jedes Bugs beschränkt sich auf einen Kunden, und Kunden, die sechsstellige Verträge unterzeichnen, zahlen für die Isolation.

Betrieblich benötigen Sie:

• Eine IaC-Pipeline (Terraform, Pulumi), die für jeden neuen Tenant eine neue Datenbank bereitstellt, Migrationen ausführt, Backups konfiguriert und Observability anbindet.
• Eine Tenant-Routing-Schicht (typischerweise ein Cloudflare Worker, ein API-Gateway oder ein In-App-Subdomain-Router), die die Tenant-ID auf den Datenbank-Connection-String abbildet.
• Einen Connection-Pool pro Tenant mit sinnvollem Idle-Eviction.
• Einen robusten Deprovisioning-Flow — eine Datenbank löschen, ihr Backup archivieren und ihren IaC-State sauber entfernen.

Auth und Identität im großen Maßstab

Im Jahr 2026 gibt es keinen guten Grund mehr, Multi-Tenant-Auth selbst zu entwickeln. Die verwalteten Optionen sind alle auf denselben Funktionsumfang konvergiert:

Gängiges Muster im Jahr 2026: Clerk oder Supabase für die Frühphase; WorkOS auf der Business-Stufe für Enterprise-SSO/SCIM ergänzen. Die Token-Verifizierung auf der API-Schicht extrahiert Tenant-ID und Benutzerrolle; der Request-Handler setzt die Postgres-GUC.

Billing, Metering und Abgleich

Ein Stripe Customer pro Tenant. Tenants werden über eine gespeicherte stripe_customer_id mit Stripe-Kunden verknüpft. Subscriptions werden in Stripe Billing verwaltet. Für nutzungsbasierte Komponenten:

• Geben Sie Nutzungs-Events aus der Anwendung an einen Event-Bus (SNS, Kafka, NATS) aus, getaggt mit Tenant-ID, Meter-Name, Menge und Idempotenz-Schlüssel.
• Ein Worker aggregiert die Nutzung pro Tenant in Ihrem internen Ledger (Postgres-Tabelle).
• Ein Abgleichs-Job läuft nächtlich, schiebt Deltas an Stripe Meters (oder Orb/Metronome/Lago) und schreibt einen täglichen Abgleichsbericht.
• Zeigen Sie Kunden die Nutzung im Produkt an — live, mit höchstens 60 s Verzögerung. Kunden vertrauen keiner undurchsichtigen Rechnung.

Die strategische Seite der Preisgestaltung haben wir in SaaS-Preismodelle im Jahr 2026 behandelt; dies ist die Engineering-Seite. Planen Sie 6–10 Wochen für produktionsreifes nutzungsbasiertes Billing ein — nicht zwei.

EU-Datenresidenz richtig gemacht

Wenn Sie in die EU verkaufen (insbesondere in regulierte Branchen oder den öffentlichen Sektor), ist „Daten bleiben in der EU" ein Beschaffungs-Häkchen, keine Marketing-Aussage. Die richtige Architektur:

1. Zwei separate Cluster: us-east-1 und eu-central-1 (oder eu-west-1 für Irland, eu-north-1 für Schweden).
2. Jedes Cluster hat sein eigenes Postgres, seinen eigenen Blob-Storage, seine eigenen Queues, Suche und Observability-Stack.
3. Tenant-zu-Cluster-Zuordnung in einem kleinen globalen Register. Der Login-Flow leitet zur korrekten regionalen API weiter.
4. Der Auth-Anbieter muss EU-Datenresidenz unterstützen (Clerk EU, WorkOS EU, Auth0 EU-Tenant).
5. Der Observability-Anbieter muss die EU unterstützen (Datadog EU, Sentry EU, Grafana Cloud EU).
6. Teilen Sie Zeilen in einer einzigen Datenbank nicht nach Region auf — Prüfer akzeptieren das nicht.

Wenn Sie mit KI-Funktionen bauen, berücksichtigen Sie auch die Region des LLM-Anbieters: Anthropic bietet EU-Endpunkte; Bedrock unterstützt eu-central-1 für Claude; Azure OpenAI bietet EU-Regionen für GPT-4o. Zur Dokumentationsseite siehe EU-AI-Act-Compliance.

Observability und Per-Tenant-SLOs

In Multi-Tenant-SaaS ist „die API ist langsam" ohne Aufschlüsselung pro Tenant bedeutungslos. Fügen Sie die Tenant-ID als erstklassige Dimension zu jeder Metrik, jedem Log und jedem Trace hinzu:

• OpenTelemetry-Traces mit dem Attribut tenant.id in jedem Span.
• Sentry-Tag tenant_id bei jedem Fehler.
• Datadog-/Grafana-Dashboards, die p50/p95/p99-Latenz und Fehlerrate pro Tenant aufschlüsseln.
• Top-10-Report der lautesten Tenants — täglich, automatisiert.
• Per-Tenant-SLOs für Ihre Top-20-Accounts. Wenn ihr SLO-Budget gefährdet ist, alarmieren Sie deren CSM, nicht nur das Engineering.

Ohne Per-Tenant-Observability sieht ein einzelner lauter Enterprise-Tenant, der p95 verschlechtert, wie ein globaler Vorfall aus. Mit ihr können Sie den Kunden zuerst anrufen.

Migrationspfade und Fallstricke

Irgendwann werden Sie migrieren. Zwei reale Pfade, die wir umgesetzt haben:

1. Gemeinsames Schema → Schema-per-Tenant. Machbar, aber mühsam. Neue Tenants landen in Schema-per-Tenant; bestehende Tenants migrieren in Batches über Dual-Write + Verifizierung + Cutover. Rechnen Sie mit 6–14 Wochen Engineering für eine Migration von 500 Tenants.
2. Single-Region → Multi-Region (EU-Datenresidenz). Bauen Sie zuerst das EU-Cluster, leiten Sie neue EU-Kunden dorthin und migrieren Sie bestehende EU-Kunden über Export + Import + Cutover mit Wartungsfenster. 8–16 Wochen.

Fallstricke, in die wir wiederholt geraten sind:

• UUIDs ohne v7. Zufällige UUIDs (v4) zermürben B-Tree-Indizes. Verwenden Sie UUID v7 (zeitlich geordnet) für alle neuen Primärschlüssel.
• Fehlende tenant_id in Nebentabellen. Audit-Log, Anhänge, Webhook-Zustelldatensätze — alle benötigen tenant_id und alle benötigen RLS.
• Langlebige Tenants mit aufgeblähten Daten. Ein Tenant mit 10 Mio. Zeilen in einer Tabelle, deren Median bei 5k liegt, bremst über Shared Buffers alle aus. Verschieben Sie ihn nach Schema-per-Tenant oder DB-per-Tenant.
• Stripe-Customer-Drift. Eine Tenant-Löschung, die Stripe-Subscriptions nicht kündigt, hinterlässt Zombie-Umsätze und Buchhaltungsprobleme.
• Hintergrund-Job-Leck. Ein für Tenant A ausgelöster Job, der Tenant B abfragt, weil der Job-Runner vergessen hat, die GUC zu setzen. Setzen Sie die GUC immer im Job-Handler; vertrauen Sie niemals dem Payload.

FAQ

Was ist eine Multi-Tenant-SaaS-Architektur?

Ein Design, bei dem eine einzige Anwendungsinstanz und eine gemeinsam genutzte Infrastruktur viele Kundenorganisationen (Tenants) gleichzeitig bedienen, während die Daten jedes Tenants logisch oder physisch isoliert bleiben. Die zentrale Entscheidung ist das Isolationsmodell: gemeinsames Schema mit Row-Level Security, Schema-per-Tenant oder Database-per-Tenant.

Welche Tenant-Isolationsstrategie ist die beste für ein neues SaaS?

Gemeinsames Schema + Postgres RLS, mit tenant_id in jeder Tabelle und der GUC pro Request gesetzt. Am einfachsten zu betreiben, am günstigsten zu skalieren, am einfachsten später zu migrieren.

Wie handhabe ich Auth in einem Multi-Tenant-SaaS?

Nutzen Sie einen verwalteten Anbieter (Clerk, Auth0, WorkOS, Supabase Auth). Ergänzen Sie WorkOS für Enterprise-SSO/SCIM auf der Business-Stufe.

Wo sollte tenant_id im Datenmodell liegen?

In jeder Tabelle, indexiert, per Fremdschlüssel verknüpft, durch RLS erzwungen. Immer.

Wie handhabe ich EU-Datenresidenz?

Getrennte EU- und US-Cluster mit eigenen Datenbanken, eigenem Storage und eigener Observability. Leiten Sie pro Tenant. Teilen Sie keine Zeilen innerhalb einer einzigen Datenbank auf.

Serverless oder Container-Runtime?

Container (Fargate, GKE Autopilot, Fly.io) für die Haupt-API; Serverless für Ränder wie Webhooks und Bildverarbeitung.

Wie rechne ich sauber über Tenants hinweg ab?

Ein Stripe Customer pro Tenant, Subscriptions verknüpft mit der internen tenant_id, nutzungsbasierte Events über Stripe Meters oder Orb/Metronome. Nächtlich abgleichen.

Bauen Sie es gleich beim ersten Mal richtig

Erzählen Sie uns von Ihrem Tenancy-Modell, Ihren Isolationsanforderungen und Ihrem Audit-Argument. Wir nennen Ihnen die günstigste Architektur, die ein 100×-Wachstum übersteht.

Zuletzt aktualisiert am 3. Juli 2026.