Multi-Tenant SaaS Architecture: Separate DB vs. Shared DB vs. Schema

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.