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

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

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 26. Mai 2026.