Ist Multi-Tenant sicher wirklich?

Ja, wenn richtig implementiert.

SaaS & Hosting

Multi-Tenant vs. Single-Tenant – Die richtige SaaS-Architektur

Kevin KrögerSaaS & HostingPublished on 2026-03-17

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

Conclusion

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.

Our Service

SaaS Products & Hosting