SaaS & Hosting
Multi-Tenant vs. Single-Tenant – Die richtige SaaS-Architektur
Nico FreitagSaaS & Hosting
Wenn du ein SaaS baust, brauchst du zu entscheiden: Multi-Tenant oder Single-Tenant? Das beeinflusst alles: Sicherheit, Skalierbarkeit, Kosten, Datenbank-Design.
Single-Tenant (Dedicated Instances)
Jeder Kunde bekommt seine eigene Instanz der Software.
Beispiel: Kunde A hat https://a.myapp.com, Kunde B hat https://b.myapp.com. Völlig separate Systeme.
```
Customer A -> Dedicated App Instance -> Dedicated Database
Customer B -> Dedicated App Instance -> Dedicated Database
```
Vorteile:
- Maximum Sicherheit (Daten sind isoliert)
- Hohe Customization möglich
- Performance ist kontrollierbar
- Compliance ist einfacher
Nachteile:
- Sehr teuer (du brauchst viele Server)
- Schwer zu skalieren
- Updates sind kompliziert (jedenServer updaten)
- Nicht ideal für kleiner Kunden
Best für: Enterprise Kunden, Highly Regulated Industries, sehr sensitive Daten
Multi-Tenant (Shared Instance)
Alle Kunden teilen sich eine Instanz.
Beispiel: Alle Kunden gehen zu myapp.com, aber haben unterschiedliche Logins und sehen nur ihre Daten.
```
Customer A -> Shared App Instance -> Shared Database
Customer B -> (filtered views)
Customer C ->
```
Vorteile:
- Billiger (eine Instanz für alle)
- Leicht zu skalieren (eine App skaliert)
- Updates sind einfach (ein Server updaten)
- Gutes für startup/SMB
Nachteile:
- Sicherheit braucht Aufmerksamkeit (isolation muss garantiert sein)
- Weniger Customization
- Noisy Neighbor Problem (ein Kunde verbraucht zu viel Resource)
- Compliance ist komplexer
Best für: Startups, SMB, weniger sensitive Daten
Technischer Unterschied: Databases
Single-Tenant:
```
Customer A: Database A (schema_customer_a)
Customer B: Database B (schema_customer_b)
```
Komplett separate Daten.
Multi-Tenant:
```
Shared Database
- customers (id, name, subscription_tier)
- orders (id, customer_id, amount)
- users (id, customer_id, email)
```
Shared Database mit `customer_id` als Tenant-Identifier.
Kritisch bei Multi-Tenant: Auf JEDEM Query Muss du filtern:
```sql
SELECT * FROM orders WHERE customer_id = 123 -- Must add customer_id!
```
Wenn du das vergisst, sieht Customer A die Daten von Customer B. BREACH!
Row-Level Security
Modern Databases haben Row-Level Security (RLS):
```sql
-- PostgreSQL Example
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY isolate_tenant ON orders
FOR ALL USING (customer_id = current_user_id);
```
Das garantiert dass jeder User nur seine Daten sieht.
Hybrid-Ansatz
Manche SaaS nutzen Hybrid:
- Small Kunden: Multi-Tenant
- Enterprise Kunden: Single-Tenant Dedicated Instances
Das beste von beiden Welten.
Welche sollte ich wählen?
Wähle Multi-Tenant wenn:
- Startup (Budget ist klein)
- Targets SMB Kunden
- Daten ist nicht highly sensitive
- Schnell skalieren brauchst
Wähle Single-Tenant wenn:
- Target Enterprise
- Daten ist very sensitive
- Compliance ist kritisch
- Customization ist wichtig
Häufige Fehler
1. "Multi-Tenant ist einfach" – Falsch, es braucht Aufmerksamkeit
2. "Ich brauche keine Isolation" – FALSCH! That's a Breach
3. "Meine Datenbank ist safe per default" – Nein, YOU must add filters
4. "Single-Tenant ist immer sicherer" – Nein, Multi-Tenant kann auch sicher sein
Fazit
Multi-Tenant vs. Single-Tenant ist eine architectural Decision. Multi-Tenant ist billiger, Single-Tenant ist sicherer. Für die meisten Startups: Multi-Tenant mit RLS ist gut.
Häufige Fragen
Weitere Artikel
SaaS & Hosting
SaaS bauen – Der Weg von Idee zum zahlenden Kunden
SaaS (Software-as-a-Service) Unternehmen zu gründen ist anders als Software zu bauen. Du musst nicht nur Software bauen ...
SaaS & HostingDocker und Kubernetes erklärt – Wenn Infrastruktur zum Code wird
Docker und Kubernetes haben die Infrastruktur revolutioniert. Mit ihnen kannst du Apps konsistent deployen, egal ob auf ...