SaaS erklärt

Multi-Tenant-Architektur – Shared Core, logische Trennung

Rund 95 % aller SaaS-Produkte setzen auf ein gemeinsames Fundament: eine Codebasis, eine Datenbankinstanz, logisch getrennte Mandanten. Die Isolation erfolgt über Row-Level Security, Schema-Prefixes oder Tenant-IDs in jedem Query. Physische Trennungen entfallen, Betriebskosten sinken, Skalierung passiert horizontal über Shared Resources.

Onboarding neuer Kunden reduziert sich auf Konfiguration – keine neue Infrastruktur, keine Migration. Updates rollt der Anbieter zentral aus; alle Mandanten profitieren gleichzeitig von Features und Security-Patches. IBM beschreibt das Modell als Standard für SMB- und Startup-SaaS, bei denen Time-to-Market und Kosteneffizienz dominieren.

Die logische Trennung verlangt careful engineering: Encryption at Rest, strikte Zugriffskontrollen, automatisierte Tests auf Tenant-Übergreifende Lecks. Ein Konfigurationsfehler betrifft potenziell alle Mandanten – der Blast-Radius ist systemisch. Wer Compliance-Anforderungen an physische Isolation stellt (BaFin, KRITIS, Gesundheitsdaten), stößt hier an Grenzen und prüft Hybrid- oder Single-Tenant-Optionen.

Single-Tenant-Architektur – Physische Isolation pro Kunde

Bei Single-Tenant erhält jeder Mandant eine dedizierte Instanz – VPC, Kubernetes-Cluster und Datenbank laufen physisch getrennt. Diese Isolation maximiert die Kontrolle über Backup-Zeitpunkte, Patch-Zyklen und Compliance-Nachweise. Laut IBM Think entfällt damit das Risiko, dass Fehlkonfigurationen eines Kunden andere Mandanten betreffen – der Blast-Radius bleibt auf die jeweilige Umgebung begrenzt.

Für regulierte Branchen ist das oft regulatorisch vorgeschrieben. BaFin-beaufsichtigte Institute, KRITIS-Betreiber und Einrichtungen im Gesundheitswesen fordern physische Trennung, um Prüfungsanforderungen nachweisbar zu erfüllen. SailPoint betont, dass Kunden so eigene Verschlüsselungsstrategien und Aufbewahrungsfristen durchsetzen können, ohne auf Anbieter-Standards angewiesen zu sein.

Der Preis für diese Autonomie: signifikant höhere Infrastrukturkosten, längeres Onboarding und meist manuelle Update-Prozesse. Während Multi-Tenant-Anbieter Patches zentral und simultan ausrollen, muss bei Single-Tenant jede Instanz einzeln gewartet werden. Inriver nennt als Konsequenz längere Release-Zyklen und höheren Betriebsaufwand pro Mandanten.

Dennoch bleibt das Modell für Enterprise-Deals mit strengen Souveränitätsvorgaben die architektonische Referenz. Wer Datenhoheit und Auditierbarkeit vor Skaleneffekten stellt, akzeptiert den Overhead bewusst – und kauft sich damit rechtliche Sicherheit ein.

Hybrid-Architektur – Best of Both Worlds durch Containerisierung

Moderne SaaS-Plattformen trennen zunehmend die Control Plane vom Data Plane. Authentifizierung, Billing und Verwaltungsoberfläche laufen multi-tenant auf einer gemeinsamen Basis – effizient, wartbar, schnell ausrollbar. Sensible Workloads hingegen wandern in dedizierte Data Planes: isolierte Kubernetes-Namespaces, eigene VPCs oder gar physische Cluster pro Kunde. Diese Granularität ermöglichen Container-Orchestrierung und Microservices-Designs, die logische Grenzen dort ziehen, wo Compliance sie verlangt.

Treiber ist nicht nur Regulierung. KI- und ML-Pipelines erzwingen physische Trennung: Trainingsdaten und Modell-Inferenz benötigen GPU-Ressourcen, strikte Datenhoheit und Audit-Trails, die sich in einer rein logischen Multi-Tenant-Datenbank kaum sauber abbilden lassen. Anbieter verschieben diese Lasten in Single-Tenant-Umgebungen, während das SaaS-Frontend multi-tenant bleibt. JetBase beschreibt diesen Trend als Reaktion auf wachsende Data-Sovereignty-Anforderungen.

AWS definiert SaaS dabei als Geschäftsmodell, nicht als starre Architekturvorgabe. Einheitliches Tenant-Management über alle Ebenen hinweg erlaubt hybride Betriebsmodelle ohne Bruch in der Developer Experience. Edana bestätigt, dass sich dieser Aufbau zum Standard für Plattformen entwickelt, die den SMB-Markt verlassen und Enterprise-Kunden mit BaFin-, KRITIS- oder Gesundheitsdaten-Anforderungen bedienen wollen.

Die Kontrolle bleibt beim Anbieter: Updates der Control Plane rollen zentral aus, Data Planes erhalten gepatchte Container-Images über CI/CD-Pipelines pro Tenant. Blast-Radius und Compliance-Nachweis verbessern sich gleichzeitig – ohne den Kostenvorteil der gemeinsamen Basis aufzugeben.

Direktvergleich – Sechs Kriterien im Überblick

Die folgende Tabelle fasst die zentralen Unterschiede zwischen den drei Architekturmustern zusammen. Sie basiert auf einer strukturierten Gegenüberstellung in der ResearchGate-Studie, den Praxiserfahrungen aus Computer Weekly und der technischen Analyse bei nOps.

Die Tabelle ist per JavaScript sortierbar (Klick auf Spaltenköpfe) und nutzt scope-Attribute für Screenreader-Navigation.

Wann Multi-Tenant die bessere Wahl ist

Multi-Tenant-Architekturen lohnen sich, wenn Geschwindigkeit und Skaleneffekte über individueller Isolation stehen. Fünf typische Szenarien:

• MVP-Validierung mit schnellem Go-to-Market: Eine gemeinsame Codebasis lässt Features in Tagen statt Wochen ausrollen – ideal für frühe Produkttests, bei denen Iterationsgeschwindigkeit über individuelle Anpassungen rangiert (MVP-Development).
• SMB-Zielgruppe mit Standard-Compliance: Kleine Kunden benötigen meist keine physische Trennung; logische Isolation per Row-Level Security und Schema-Prefixes genügt, um Datenschutzanforderungen kostengünstig zu erfüllen (Ryveris).
• Hohe Tenant-Anzahl bei geringem ARPU: Kostenvorteile pro Mandant entstehen durch geteilte Infrastruktur, gebündelte Lizenzkosten und automatisierte Updates, die sich über tausende Instanzen amortisieren (Clerk).
• Häufige Feature-Releases gewünscht: Zentrale Deployments vermeiden Versionsfragmentierung, reduzieren Regressionstests und ermöglichen Continuous Delivery ohne koordinatorischen Overhead pro Kunde.
• Begrenzte DevOps-Ressourcen für Tenant-Management: Einheitliche Monitoring-, Backup- und Security-Patching-Prozesse entlasten kleine Teams, da keine dedizierten Umgebungen pro Kunde betrieben werden müssen.

Wer diese Muster erkennt, senkt Cost-per-Tenant und hält die Plattform wartbar.

Wann Single-Tenant die bessere Wahl ist

Single-Tenant-Architekturen rechtfertigen ihren höheren Aufwand dort, wo regulatorische Härte oder individuelle Steuerbarkeit den Ausschlag geben. Fünf Szenarien zeigen die Grenze zum Multi-Tenant-Standard:

• Enterprise-Deals mit Audit-Pflicht: ISO-27001- oder SOC-2-Type-II-Prüfungen verlangen oft nachweisbar getrennte Backups, eigene Verschlüsselungsschlüssel und revisionssichere Update-Fenster – physische Isolation liefert diese Beweise einfacher als logische Trennungen.
• BaFin- und KRITIS-regulierte Workloads: Finanzaufsicht und BSI-Kritisverordnung fordern dedizierte Kontrollpunkte. Ein deutscher Rechenzentrumsbetreiber betont, dass physische Mandanten-Trennung im eigenen Rechenzentrumsverbund die Compliance-Dokumentation gegenüber Prüfern erheblich verkürzt (TelemaxX-Praxisbericht).
• Kundenspezifische Release-Zyklen und Customizations: Wenn Großkunden Hotfix-Zeitfenster, individuelle Modul-Konfigurationen oder eigene CI/CD-Pipelines verlangen, stößt ein einheitlicher Multi-Tenant-Release-Train an organisatorische Grenzen.
• Datenhoheits-Gesetze: EU Data Act, Schweizer DSG oder sektorspezifische Lokalisierungsgebote erzwingen speicherortgenaue Kontrolle. Ein Identity-Security-Spezialist warnt, dass gemeinsame Identitäts-Infrastrukturen bei grenzüberschreitenden Mandaten das Blast-Radius-Risiko erhöhen (Ping-Identity-Analyse).
• Migration von On-Prem-Legacy mit 1:1-Abgleich: Wer bestehende Applikationen ohne Refactoring in die Cloud heben will, nutzt Single-Tenant als „Lift-and-Shift“-Ziel – identische IP-Ranges, Zertifikatsketten und Backup-Rhythmen bleiben erhalten (Axisport-Entscheidungshilfe).

Wann Hybrid-Architektur die bessere Wahl ist

Hybride Modelle lohnen sich, wenn sich Anforderungen nicht mehr rein logisch, sondern physisch trennen lassen. Fünf typische Szenarien:

• Plattformen mit wachsendem Enterprise-Anteil auf SMB-Basis: Der Kern bleibt Multi-Tenant, sensible Kunden erhalten dedizierte Daten-Planes – ScaleVista nennt dies „Tenant-Aware Control Plane“.
• KI-Features mit isolierten GPU-Clustern für Trainingsdaten: Inferenz läuft shared, Training landet in Single-Tenant-Instanzen, um Compliance und Performance zu garantieren.
• Data-Sovereignty-Pflicht nur für Teilmengen (PII, Gesundheitsdaten): Physische Separation in EU-Rechenzentren, während Metadaten und UI global multi-tenant betrieben werden.
• Schrittweise Migration von Single- zu Multi-Tenant: Legacy-Kunden bleiben auf dedizierten Instanzen, Neukunden starten sofort im Shared-Core – DZone beschreibt diesen Pfad als „Strangler Fig Pattern“.
• Multi-Region-Deployments mit lokaler Datenhaltung: Edge-Nähe für Latenz, rechtliche Speicherortbindung pro Jurisdiktion.

FinOps wird dabei zum Steuerungsinstrument: Edana betont, dass Tenant-aware Cost Allocation nur funktioniert, wenn Control Plane und Data Plane sauber getrennte Abrechnungsmetriken liefern. Ohne diese Granularität verschwimmen die Kostenvorteile des Hybrid-Betriebs.

Technische Tiefe – Isolationstrategien im Detail

Multi-Tenant-Implementierungen unterscheiden sich grundlegend in der Datentrennung. Schema-basierte Ansätze nutzen getrennte Schemata innerhalb einer Datenbank – einfache Migration, aber gemeinsamer Connection-Pool. Row-Level Security (RLS) filtert über Policies pro Tenant; Clerk betont, dass RLS bei komplexen Joins Leistungsgrenzen erreicht. Datenbank-pro-Tenant liefert physische Isolation, treibt aber Betriebskosten und Migrationsaufwand.

Single-Tenant-Deployments provisionieren eigene VPCs, dedizierte Kubernetes-Cluster und separate Control Planes. Jeder Kunde erhält unabhängige Update-Zyklen, Backup-Fenster und Netzwerk-Perimeter. Der Blast-Radius bei Fehlkonfiguration bleibt auf eine Instanz begrenzt.

Hybride Architekturen kombinieren Shared Control Plane (Auth, Billing, UI) mit Tenant-scoped Data Planes. Namespaces und Network-Policies in Kubernetes kapseln Workloads pro Mandant. JetBase empfiehlt, sensible Microservices (Zahlung, KI-Inferenz) in Single-Tenant-Pods auszulagern, während Frontend und API-Gateway multi-tenant bleiben.

Observability muss Tenant-Kontext tragen: Logs, Metriken und Traces erhalten Tenant-IDs als Labels. OpenTelemetry-Collector routen Telemetrie in getrennte Backends oder Partitionen. Encryption-at-Rest nutzt pro Tenant eigene KMS-Keys; In-Transit erzwingt mTLS zwischen Data Planes. Heise warnt: Logische Isolation scheitert oft an fehlender Testabdeckung für Cross-Tenant-Leaks.

Zukunftstrends & Entscheidungsframework 2026+

NIS2 und der EU Data Act verschärfen die Datensouveränität massiv. Hybrid wird zum Standard für Plattformen, die über den SMB-Markt hinauswachsen wollen. KI-Workloads erzwingen dedizierte Compute-Ebenen: Trainingsdaten und Inferenz laufen in isolierten GPU-Clustern, während das SaaS-Frontend multi-tenant bleibt. FinOps-Tools wie nOps oder CloudHealth machen Tenant-Kosten erstmals granular transparent.

Ein pragmatischer Entscheidungsbaum: Startups beginnen mit Multi-Tenant. Erreicht ein Enterprise-Deal den Verhandlungstisch, prüft man die Hybrid-Option. Fordert Compliance physische Trennung, führt kein Weg an Single-Tenant vorbei. Die Edana-Analyse bestätigt: Container und Kubernetes ermöglichen granulare Isolation – Shared Core für Auth, Billing, UI plus dedizierte Data Planes für sensible Workloads.

Gefährlich ist der frühe Griff zum Single-Tenant ohne Migrationspfad. Wer hier „Architecture Lock-in“ baut, zahlt später doppelt: für dedizierte Infrastruktur und für den späteren Umbau auf Hybrid. Computer Weekly warnt vor genau diesem Pfad: ERP-Kunden unterschätzen den Aufwand, isolierte Instanzen wieder in eine gemeinschaftliche Plattform zu überführen.

Die tanstackship-Prognose sieht Multi-Tenant bei ~95 % aller SaaS-Produkte – aber die verbleibenden Enterprise-Kunden generieren oft den Großteil des Umsatzes. Wer 2026+ skalieren will, plant Hybrid von Tag