Multi-Tenant SaaS Architektur: Separate DB vs. Shared DB vs. Schema-Based

Wenn du ein SaaS-Produkt entwickelst, kommt sehr früh eine Entscheidung, die vielen Gründern nicht bewusst ist:

Wie trenne ich die Daten meiner Kunden technisch?

Die Entscheidung beeinflusst:

• Sicherheit
• Skalierbarkeit
• Betriebskosten
• Risiko und Haftung
• Komplexität der Weiterentwicklung

Viele Startups stürzen sich auf Features, bevor die Architektur steht. Die Folge ist oft ein späterer, teurer Re-Write – nur weil das Fundament falsch gewählt wurde.

Was bedeutet Multi-Tenant?

Multi-Tenant heißt:

Eine Softwareinstanz bedient mehrere Kunden (Tenants). Alle nutzen dieselbe App, aber jeder sieht nur seine Daten.

Ein Tenant kann sein:

• ein Unternehmen
• eine Organisation
• ein Kunde mit mehreren Nutzern

Multi-Tenant ist die Grundlage jedes modernen SaaS.

Es gibt drei gängige Architektur-Varianten

Wir gehen sie jetzt durch.

1. Shared Database, Shared Schema

(alle Kunden in denselben Tabellen)

Beispiel:

Eine Tabelle customers, eine Tabelle orders, und jede Zeile hat ein Feld tenant_id.

Vorteile:

• einfach zu implementieren
• kleine Hostingkosten
• ideal für MVPs und frühes Testing

Risiken:

• Datenleak bei einem Bug ist existenzbedrohend
• komplex bei späterer Skalierung
• große Tabellen können langsam werden

Geeignet für:

• MVP
• frühe Phase
• B2C oder kleine Kunden

Nicht geeignet, wenn Daten sehr sensibel sind.

2. Shared Database, Separate Schema

(gleiche DB, aber pro Tenant ein eigenes Schema)

Beispiel:

public.customer tenant_1.customer tenant_2.customer tenant_3.customer

Vorteile:

• starke Datenisolation ohne viele Datenbanken
• saubere Trennung pro Kunde
• einfacheres Datenmanagement als beim Shared Schema

Nachteile:

• mehr DevOps Aufwand
• Migrationslogik muss tenantsicher sein

Geeignet für:

• B2B SaaS mit Firmenkunden
• Mandantenfähigkeit mit Compliance-Anforderungen

Diese Architektur nutzen viele moderne SaaS-Produkte (Django / PostgreSQL unterstützen das sehr gut).

3. Separate Database per Tenant

(jeder Kunde erhält seine eigene Datenbank)

Vorteile:

• maximale Sicherheit
• einfaches Backup und Restore pro Kunde
• sehr guter Fit für Enterprise-Kunden

Nachteil:

• größter DevOps-Aufwand
• komplexes Rollout für Migrationsprozesse

Geeignet für:

• Enterprise SaaS
• kritische Daten
• DSGVO/ISO-relevante Branchen

Wenn ein Kunde eine separate Datenbank fordert, ist das der Standard.

Entscheidungsbaum

Wenn du:

• ein MVP baust → Shared DB, Shared Schema
• KMU / B2B Kunden bedienen willst → Shared DB, Separate Schema
• Enterprise + Compliance benötigst → Separate DB

Die Architektur kostet dich heute wenige Stunden. Oder in einem Jahr mehrere Monate Re-Write.

Typischer Fehler von Non-Tech-Foundern

Sie lassen Code entwickeln, ohne zu wissen:

• wie Tenant-Isolation umgesetzt ist
• ob Daten getrennt oder vermischt gespeichert werden
• ob das System später skalieren kann

Wenn du das nicht verstehst, gehörst du dem Entwickler – nicht dein Produkt.

Fazit

Du wählst keinen Tech-Stack nur, um Software zu bauen. Du wählst einen Tech-Stack, um ein Unternehmen skalieren zu können.

Die richtige Multi-Tenant-Architektur entscheidet:

• ob du schnell onboarden kannst,
• ob du Kunden mit Sicherheitsanforderungen bedienen kannst,
• ob du später nicht komplett neu bauen musst.

Wenn du nicht sicher bist, welche Architektur dein SaaS braucht: Wir begleiten dich bei der Architekturentscheidung und bauen skalierbare MVPs, die investierbar sind. Lies auch: Warum du keine Microservice-Architektur brauchst und Django Performance: 10 Tipps.