Single-Tenant oder Multi-Tenant: welche Architektur für eine SaaS-Anwendung?
Aktualisiert: 2026-11
Multi-Tenant mit einer gemeinsamen Anwendung und sauber getrennten Daten ist für die meisten SaaS-Produkte die wirtschaftlichere Wahl: ein Betrieb, ein Update, geringere Kosten pro Kunde. Single-Tenant lohnt sich, wenn einzelne Kunden vertraglich oder regulatorisch eine eigene Instanz verlangen, starke Anpassungen brauchen oder sehr unterschiedliche Lasten erzeugen.
Die Frage nach der Mandantenarchitektur fällt früh und ist später teuer zu ändern. Sie bestimmt Betriebskosten, Sicherheitsmodell, Update-Prozess und die Art, wie Kunden auf ihre Daten zugreifen.
Dazwischen gibt es Mischformen: eine gemeinsame Anwendung mit getrennten Datenbanken oder Schemas pro Kunde, oder Multi-Tenant als Standard mit dedizierten Instanzen für einzelne grosse Kunden.
Im direkten Vergleich
| Kriterium | Single-Tenant | Multi-Tenant |
|---|---|---|
| Betriebskosten | Höher, eine Instanz pro Kunde. | Tiefer, Infrastruktur wird geteilt. |
| Updates | Pro Kunde, Versionen können auseinanderlaufen. | Einmal für alle. |
| Datentrennung | Physisch getrennt. | Logisch getrennt, etwa mit Row Level Security; muss konsequent umgesetzt sein. |
| Anpassbarkeit | Kundenspezifische Anpassungen möglich. | Konfiguration statt Code pro Kunde. |
| Regulatorik | Erleichtert Anforderungen an eigene Instanz oder Standort. | Erfordert Nachweise zur Trennung. |
| Skalierung | Pro Kunde steuerbar. | Gemeinsam; laute Nachbarn müssen begrenzt werden. |
Wann Single-Tenant besser ist
- —Kunden verlangen vertraglich eine eigene Instanz oder einen bestimmten Datenstandort.
- —Einzelne Kunden brauchen tiefe Anpassungen, die nicht über Konfiguration abbildbar sind.
- —Die Zahl der Kunden ist klein und ihr Volumen gross.
Wann Multi-Tenant besser ist
- —Das Produkt richtet sich an viele kleine und mittlere Kunden mit ähnlichen Anforderungen.
- —Schnelle Releases für alle sind wichtiger als kundenspezifische Versionen.
- —Die Datentrennung kann technisch sauber umgesetzt und geprüft werden.
Unsere Einschätzung
Für die meisten SaaS-Produkte im KMU-Umfeld ist Multi-Tenant mit Mandantentrennung auf Datenbankebene der richtige Start. Unsere eigenen Produkte setzen dafür auf Row Level Security in Postgres.
Wer früh weiss, dass einzelne Grosskunden eine eigene Instanz brauchen werden, plant die Architektur so, dass diese Option später möglich ist, ohne das Produkt zu verzweigen.
Übergeordnete Leistung: SaaS-Produktentwicklung
Passende Angebote
Multi-Tenant-SaaS-Architektur
Dieses Paket legt das Architektur-Fundament für skalierbares SaaS: strikte Mandantentrennung, ein sauberes Rollen- und Rechtemodell und eine Struktur, die mitwächst. Ergebnis ist eine Basis, auf der Sie Funktionen bauen können, ohne dass Sicherheit und Skalierbarkeit zur nachträglichen Baustelle werden.
SaaS Security & RLS Audit
Ein SaaS-Security-Audit prüft gezielt die Mandantentrennung: Ist Row-Level-Security wasserdicht, greift die Zugriffskontrolle, sind typische Supabase-Fallen (Service-Role im Client, fehlende RLS) vermieden? Ergebnis ist ein Befund mit konkreten Fixes.
Next.js-Webapplikation zum Festpreis
Eine massgeschneiderte Webapplikation auf Next.js — schnell, SEO-stark und wartbar, mit klar umrissenem Funktionsumfang und verbindlichem Festpreis. Ergebnis ist eine produktionsreife Anwendung ohne die üblichen Kostenüberraschungen offener Stundenabrechnung.
Häufige Fragen
Ist Multi-Tenant weniger sicher?
Nicht grundsätzlich. Entscheidend ist, dass die Trennung konsequent auf Datenbankebene erzwungen und regelmässig geprüft wird.
Kann man später wechseln?
Von Multi- zu Single-Tenant für einzelne Kunden ja, wenn die Architektur das vorsieht. Der umgekehrte Weg ist meist ein grösserer Umbau.
Was ist mit Datenexport bei Kündigung?
In beiden Modellen sollte ein vollständiger Export pro Kunde möglich sein; das ist auch eine Frage der Datenportabilität.