Eine gemeinsame Datenbank, die an ihre Grenzen stößt
Sie sind mit 10 Kunden in einer einzigen Datenbank gestartet. Heute, bei 200, werden Abfragen langsamer, Berichte dauern, und ein einzelner Kunde kann das System für alle anderen ausbremsen.
Das Problem
Schlecht umgesetzte Mandantenfähigkeit: die teuerste technische Schuld überhaupt
Diese Symptome sehen wir, wenn ein SaaS wächst, ohne dass die Multi-Tenant-Architektur von Anfang an mitgedacht wurde.
Ohne echte Datentrennung unterschreiben große Kunden nicht
Verlangt ein Großunternehmen Sicherheitszertifizierungen wie ISO 27001 oder SOC 2, reicht es nicht zu sagen, dass seine Daten mit denen anderer in derselben Tabelle liegen. Sie brauchen eine echte, nachweisbare Trennung.
Jedes Update ist ein Glücksspiel
Jede Änderung an der Datenbank betrifft alle gleichzeitig. Geht etwas schief, merken es alle Ihre Kunden. Und es gibt kein Zeitfenster für eine Abschaltung: Mit Kunden in Europa und Amerika arbeitet immer jemand.
Neukunden von Hand anlegen
Die Aktivierung eines neuen Kontos erfordert manuelle Abläufe, Konfiguration und das Einspielen von Startdaten. Ihr Vertrieb braucht Tage, um eine kostenlose Testphase freizuschalten – und in der Zwischenzeit gehen Ihnen Abschlüsse verloren.
Isolationsmodelle
Vier Wege, die Daten Ihrer Kunden zu trennen – wir wählen den passenden
Es gibt nicht das eine richtige Muster. Wir wägen Kosten, Betriebsaufwand und Compliance-Anforderungen ab und wählen das optimale Modell für Ihre Kundenzahl und die Tarife, die Sie verkaufen.
Eine Datenbank pro Kunde
Maximale Isolation, ideal für Enterprise-Kunden. Unabhängige Backups, und Zertifizierungsaudits (ISO 27001, SOC 2) lassen sich leicht bestehen.
Ein eigener Bereich pro Kunde
Jeder Kunde hat einen eigenen Bereich innerhalb derselben Datenbank. Eine gute Balance zwischen einfachem Betrieb und Kostenkontrolle.
Gemeinsame Datenbank mit automatischen Filtern
Alle Kunden teilen sich dieselben Tabellen, doch dank integrierter Zugriffsregeln sieht jeder nur seine eigenen Daten. Sehr effizient bei einer sehr großen Zahl kleiner Kunden.
Hybrid nach Tarif
Ihre Free- und Starter-Kunden in einer gemeinsamen Datenbank, Ihre Enterprise-Kunden mit eigener Datenbank. Geringere Kosten, ohne bei den Anforderungen der Großen Abstriche zu machen.
Architektur
Eine Plattform. Daten pro Kunde getrennt. Gemeinsame Dienste.
So gelangt jede Nutzeraktion vom Browser bis zu den Daten: Die Webadresse (zum Beispiel kunde1.ihreapp.com) zeigt, um welchen Kunden es sich handelt, ein sicherer digitaler Nachweis bestätigt die Identität, die Dienste skalieren bei Bedarf automatisch, und alle Messwerte werden pro Kunde gekennzeichnet, damit sich Störungen präzise diagnostizieren lassen.
Kunde A
acme.app
Enterprise · Dedizierte DB
Kunde B
globex.app
Pro · Dediziertes Schema
Kunde C
initech.app
Starter · Gemeinsame DB + RLS
Edge / CDN
Cloudflare oder CloudFront, Routing über subdomain.kunde.app
Ingress + Auth
API-Gateway + JWT-Token mit Kunden-ID und Nutzungslimits pro Kunde
Anwendungsdienste
So ausgelegt, dass sie bei wachsender Nutzerzahl automatisch Kapazität hinzufügen, ohne dass jemand eingreifen muss.
Datenspeicher
Wir nutzen Datenbanken mit Zugriffsregeln, die die Informationen jedes Kunden automatisch trennen, oder mehrere unabhängige Datenbanken – je nachdem, wie viel Isolation Sie brauchen.
Monitoring
Kennzahlen, Aktivitätsprotokolle und Traces, gekennzeichnet mit dem Label des jeweiligen Kunden, um Störungen gezielt zu finden und zu beheben, ohne andere zu beeinträchtigen.
Bewährt im großen Maßstab
Echte Zahlen unserer Multi-Tenant-Plattformen im Livebetrieb
Aggregierte Daten aus laufenden Projekten, die auf unserer Multi-Tenant-Architektur basieren.
1.000+
aktive Kunden parallel in Projekten im Livebetrieb
<150ms
p99-Antwortzeit bei Datentrennung pro Kunde
99,95%
SLA möglich mit Multi-AZ und Failover
0
Datenlecks zwischen Kunden dank strikter Isolation
Kundenlebenszyklus
Von der Registrierung bis zur Nutzung Ihres Produkts in Minuten statt Tagen
Der komplette automatische Onboarding-Prozess, sobald ein Neukunde sein Konto aktiviert – ohne manuellen Aufwand für Ihren Vertrieb.
01
Registrierung
Der Kunde registriert sich, bestätigt seine E-Mail-Adresse und wählt einen Tarif. Subdomain und eindeutige ID werden reserviert.
02
Provisioning
Die Ressourcen des Kunden werden angelegt: sein getrennter Datenbereich, Secrets, Startinhalte und Standardeinstellungen.
03
Aktivierung
Geführte Tour, erster Admin angelegt, SSO-Integrationen und Basis-Branding. Der Kunde ist aktiv und wird abgerechnet.
04
Betrieb
Live-Kennzahlen pro Kunde: Nutzung, Umsatz, Fehler, Performance. Kontrollierte Updates und Migrationen mit Feature Flags.
Säulen der Skalierbarkeit
Vier Disziplinen, die die Plattform tragen, wenn Tausende Kunden kommen
Technische Entscheidungen, die spätere schmerzhafte Neuentwicklungen vermeiden: Auto-Scaling, selektives Sharding, Caching und feingranulare Observability.
Auto-Scaling
HPA in Kubernetes, On-Demand-Instanzen und Warm Pools. Die Plattform reagiert auf echten Traffic, ohne dass jemand eingreifen muss.
Sharding
Datenpartitionierung nach Kunde oder Region, sobald das Volumen wächst. Wir isolieren die ressourcenintensivsten Kunden, ohne den Rest zu beeinträchtigen.
Caching
Redis pro Kunde für Sessions und häufige Abfragen. CDN für Bilder und Assets. Weniger Last auf der Datenbank, weniger Wartezeit für den Endnutzer.
Observability
Metriken, Logs und Traces, gekennzeichnet mit der Kunden-ID. Punktgenaues Debugging von Störungen, ohne den Gesamtüberblick zu verlieren.
Häufige Fragen
Häufige Fragen zur Multi-Tenant-SaaS-Entwicklung
Was kostet die Entwicklung eines Multi-Tenant-SaaS?
Die Kosten hängen von den Modulen, der Datentrennung, dem Onboarding und der Abrechnung ab. Die erste Version und ihre Weiterentwicklung legen wir in einem Angebot mit festem Umfang, Zeitplan und Festpreis fest.
Welchen Stack nutzen Sie für Multi-Tenancy?
Backend je nach Bedarf in Node.js, Python oder PHP, als Datenbank vorwiegend Postgres mit Row-Level Security (RLS), Infrastruktur auf AWS, DigitalOcean oder GCP. Kubernetes, wenn echtes Auto-Scaling nötig ist.
Migrieren Sie auch ein bestehendes SaaS auf eine Multi-Tenant-Architektur?
Ja. Das ist ein gängiges Muster: Sie starten mit einem Kunden und entwickeln Ihr Produkt dann zur Multi-Tenant-Lösung weiter. Wir planen die Migration in Phasen und ohne Datenverlust.
Wie wird die Nutzung pro Kunde abgerechnet?
Wir erfassen Verbrauchskennzahlen (Nutzer, Requests, Speicher, KI-Aufrufe) und übergeben sie an Stripe Billing oder ein anderes Abrechnungssystem für die automatische Rechnungsstellung.
Ist das mit ISO 27001 / SOC 2 vereinbar?
Ja. Wir entwickeln mit nachweisbarer Datentrennung, Audit-Logs pro Mandant und Verschlüsselung im Ruhezustand und bei der Übertragung. Bei der Prüfung unterstützen wir Ihr Compliance-Team.
Braucht Ihr SaaS eine mandantenfähige Architektur?
Wir analysieren Ihre aktuelle Plattform und planen den Weg zur Multi-Tenant-Architektur – ohne unnötige Neuentwicklung.