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

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

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!

Manche SaaS nutzen Hybrid: - Small Kunden: Multi-Tenant - Enterprise Kunden: Single-Tenant Dedicated Instances Das beste von beiden Welten.

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