Multi-Tenant vs Single-Tenant | Die richtige SaaS-Architektur wahlen

Jedes SaaS-Produkt muss eine fundamentale Frage beantworten: Wie bedienen Sie mehrere Kunden mit derselben Software? Die Antwort ist Ihr Tenancy-Modell. Es beeinflusst Kosten, Sicherheit, Performance und wie schnell Sie liefern konnen. Es fruh richtig zu machen, erspart Ihnen schmerzhafte Migrationen spater.

Definitionen

Multi-Tenant

Eine Instanz der Anwendung bedient alle Kunden. Jeder teilt sich die gleichen Server, die gleiche Codebasis und oft die gleiche Datenbank. Die Daten jedes Kunden sind logisch isoliert, aber die Infrastruktur wird geteilt.

Stellen Sie es sich wie ein Mehrfamilienhaus vor. Jeder Mieter wohnt im selben Gebaude, teilt sich Aufzug und Flure, hat aber seine eigene abgeschlossene Wohnung mit eigener Einrichtung.

Single-Tenant

Jeder Kunde bekommt seine eigene dedizierte Instanz der Anwendung. Separate Server, separate Datenbanken, manchmal separate Codebasen. Nichts wird zwischen Kunden geteilt.

Stellen Sie es sich wie Einzelhauser vor. Jeder Mieter hat sein eigenes Gebaude, seine eigenen Leitungen, seinen eigenen Garten. Vollstandige Isolation, aber teurer in der Wartung.

Wie Multi-Tenancy funktioniert

Es gibt drei gangige Ansatze fur Multi-Tenant-Architektur, jeder mit unterschiedlichen Kompromissen.

Modell 1: Geteilte Anwendung, geteilte Datenbank

Alle Mandanten teilen sich eine einzelne Anwendungsinstanz und eine einzelne Datenbank. Mandantendaten werden durch einen Mandantenbezeichner (normalerweise eine tenant_id-Spalte) in jeder Tabelle getrennt.

Architektur:

• Ein Anwendungsserver (oder Cluster) verarbeitet alle Anfragen.
• Eine Datenbank speichert alle Mandantendaten.
• Jede Abfrage enthalt eine WHERE tenant_id = ?-Klausel, um Daten auf den richtigen Mandanten einzugrenzen.

Vorteile:

• Niedrigste Infrastrukturkosten. Eine Datenbank, ein App-Deployment.
• Am einfachsten zu deployen und zu aktualisieren. Einmal pushen, alle bekommen die Anderung.
• Einfach, Daten uber Mandanten hinweg fur Analysen und Reporting zu aggregieren.

Nachteile:

• Hochstes Risiko von Datenlecks, wenn eine Abfrage den Mandantenfilter vergisst.
• Ein “lauter” Mandant kann die Performance fur alle verschlechtern.
• Datenbankmigrationen betreffen alle Mandanten gleichzeitig.
• Am schwierigsten, Datenresidenz-Vorschriften zu erfullen.

Das ist der haufigste Ansatz fur B2B-SaaS-Produkte mit einer grossen Anzahl kleiner bis mittelgrosser Kunden.

Modell 2: Geteilte Anwendung, separate Datenbanken

Alle Mandanten teilen sich die gleiche Anwendungsinstanz, aber jeder Mandant bekommt seine eigene Datenbank. Die Anwendung leitet Abfragen basierend auf dem authentifizierten Mandanten an die richtige Datenbank.

Architektur:

• Ein Anwendungsserver (oder Cluster) verarbeitet alle Anfragen.
• Eine separate Datenbank fur jeden Mandanten.
• Eine Routing-Schicht ordnet die Mandantenidentitat der richtigen Datenbankverbindung zu.

Vorteile:

• Starkere Datenisolation. Kein Risiko mandantenübergreifender Abfragen.
• Einfacher, Datenresidenz-Anforderungen zu erfullen. Sie konnen jede Datenbank in der geforderten Region des Mandanten platzieren.
• Backup und Restore pro Mandant ist unkompliziert.
• Hohe Nutzung eines Mandanten sperrt keine Tabellen fur andere Mandanten.

Nachteile:

• Mehr Infrastruktur zu verwalten. Hunderte Mandanten bedeuten Hunderte Datenbanken.
• Schema-Migrationen mussen auf jede Datenbank einzeln angewendet werden.
• Mandantenübergreifendes Reporting erfordert Abfragen uber mehrere Datenbanken.
• Hohere Kosten als ein vollstandig geteiltes Modell.

Das ist ein starker Mittelweg fur Produkte, die bessere Isolation brauchen, ohne die Kosten voller Single-Tenancy.

Modell 3: Separate Anwendung, separate Datenbank

Jeder Mandant bekommt seine eigene Anwendungsinstanz und seine eigene Datenbank. Vollstandig isoliert. Das ist im Grunde Single-Tenancy, aber vom SaaS-Anbieter verwaltet statt vom Kunden.

Architektur:

• Ein dediziertes Anwendungs-Deployment pro Mandant.
• Eine dedizierte Datenbank pro Mandant.
• Eine Routing-Schicht (oft ein Load Balancer oder API Gateway) leitet Traffic an die richtige Instanz.

Vorteile:

• Vollstandige Isolation. Keine geteilten Ressourcen zwischen Mandanten.
• Maximale Flexibilitat fur Anpassung pro Mandant.
• Performance eines Mandanten beeinflusst nie einen anderen.
• Einfachste Compliance-Geschichte.

Nachteile:

• Hochste Infrastrukturkosten bei weitem.
• Deployment-Komplexitat wachst linear mit der Mandantenanzahl.
• Updates mussen auf jede Instanz einzeln ausgerollt werden (oder sehr sorgfaltig automatisiert).
• Skaliert wirtschaftlich nicht fur grosse Zahlen kleiner Mandanten.

Dieses Modell ergibt Sinn fur Enterprise-SaaS, bei dem Kunden dedizierte Infrastruktur verlangen und bereit sind, einen Aufpreis dafur zu zahlen.

Vor- und Nachteile im Uberblick

Faktor	Multi-Tenant (Geteilte DB)	Multi-Tenant (Separate DB)	Single-Tenant
Infrastrukturkosten	Niedrigste	Mittel	Hochste
Datenisolation	Logisch (Zeilenebene)	Physisch (Datenbankebene)	Vollstandig
Deployment-Komplexitat	Niedrig	Mittel	Hoch
Update-Geschwindigkeit	Sofort fur alle	Sofortige App, Pro-DB-Migrationen	Pro-Instanz-Rollout
Anpassung	Begrenzt	Begrenzt	Voll
Compliance	Schwieriger	Moderat	Am einfachsten
Skalierbarkeit (Mandantenanzahl)	Exzellent	Gut	Schlecht
Noisy-Neighbor-Risiko	Hoch	Mittel	Keines

Datenisolation und Sicherheit

Datenisolation ist die wichtigste Uberlegung bei jedem Tenancy-Modell. Eine Sicherheitsverletzung, bei der ein Mandant auf die Daten eines anderen zugreifen kann, ist katastrophal fur ein SaaS-Geschaft. Es kann Vertrauen zerstoren, Vorschriften verletzen und das Unternehmen beenden.

Row-Level Security

Im geteilten Datenbankmodell ist PostgreSQLs Row-Level Security (RLS) eine der starksten Verteidigungen gegen Datenlecks. RLS erzwingt Mandantenisolation auf Datenbankebene, nicht auf Anwendungsebene. Selbst wenn Ihr Anwendungscode einen Bug hat, der vergisst, nach Mandant zu filtern, verhindert die Datenbank selbst mandantenübergreifenden Zugriff.

So richten Sie es ein:

-- RLS auf einer Tabelle aktivieren
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Eine Policy erstellen, die Zugriff auf den aktuellen Mandanten beschrankt
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- RLS auch fur Tabelleneigentumer erzwingen
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Vor der Ausfuhrung jeder Abfrage den Mandantenkontext setzen:

-- Am Anfang jeder Anfrage/Transaktion setzen
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Diese Abfrage gibt jetzt automatisch nur die Daten des aktuellen Mandanten zuruck
SELECT * FROM projects;
-- Keine WHERE-Klausel notig. RLS ubernimmt das.

Isolation auf Anwendungsebene

Zusatzlich zur Sicherheit auf Datenbankebene sollte Ihre Anwendung Mandantengrenzen durchsetzen:

// Middleware, die den Mandantenkontext bei jeder Anfrage setzt
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // Aus JWT, Subdomain oder Header

  if (!tenantId) {
    return res.status(401).json({ error: "Tenant not identified" });
  }

  // Mandantenkontext fur die Datenbankverbindung setzen
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

Defense in Depth ist hier das Prinzip. Verlassen Sie sich nie auf eine einzige Isolationsschicht. Kombinieren Sie Filterung auf Anwendungsebene, Sicherheit auf Datenbankebene und regelmaessige Sicherheitsaudits.

Performance-Uberlegungen

Herausforderungen der geteilten Datenbank

In einer geteilten Datenbank konkurrieren alle Mandanten um dieselben Ressourcen. Ein Mandant, der einen aufwendigen Report ausfuhrt, kann Abfragen fur alle anderen verlangsamen. Massnahmen:

• Connection Pooling. Nutzen Sie PgBouncer oder ein ahnliches Tool, um zu verhindern, dass ein Mandant Datenbankverbindungen erschopft.
• Query-Timeouts. Setzen Sie maximale Ausfuhrungszeiten, damit eine ausser Kontrolle geratene Abfrage nicht unbegrenzt Ressourcen blockiert.
• Rate Limiting. Erzwingen Sie Pro-Mandant-Limits fur API-Anfragen und Datenbankoperationen.
• Read Replicas. Leiten Sie aufwendige Leseoperationen (Reports, Exporte) an ein Replikat, damit sie die primare Datenbank nicht beeintrachtigen.

Vorteile separater Datenbanken

Mit Pro-Mandant-Datenbanken ist Performance-Isolation eingebaut. Der aufwendige Workload eines Mandanten beeinflusst nur seine eigene Datenbank. Sie konnen auch grossere oder kleinere Datenbanken basierend auf dem Plan und der Nutzung jedes Mandanten bereitstellen.

Der Kompromiss ist Verwaltungsaufwand. 500 Datenbanken zu uberwachen ist schwieriger als eine. Automatisiertes Tooling wird essenziell.

Kostenimplikationen im grossen Massstab

Schauen wir uns grobe Zahlen an. Angenommen, Sie haben 100 Mandanten.

Geteilte Datenbank (Multi-Tenant):

• 1 Anwendungscluster: ~200 EUR/Monat
• 1 verwaltete PostgreSQL-Instanz: ~100 EUR/Monat
• Gesamt: ~300 EUR/Monat (3 EUR pro Mandant)

Separate Datenbanken (Multi-Tenant):

• 1 Anwendungscluster: ~200 EUR/Monat
• 100 kleine Datenbankinstanzen: ~2.000 EUR/Monat
• Gesamt: ~2.200 EUR/Monat (22 EUR pro Mandant)

Single-Tenant:

• 100 Anwendungsinstanzen: ~5.000 EUR/Monat
• 100 Datenbankinstanzen: ~2.000 EUR/Monat
• Gesamt: ~7.000 EUR/Monat (70 EUR pro Mandant)

Diese Zahlen sind vereinfacht, aber das Muster halt. Geteilte Infrastruktur ist dramatisch gunstiger. Bei 1.000 Mandanten wird der Abstand noch grosser.

Deshalb muss die Preisgestaltung zur Architektur passen. Wenn Sie 20 EUR pro Monat berechnen und Single-Tenant-Infrastruktur fur 70 EUR pro Mandant betreiben, verlieren Sie bei jedem Kunden Geld.

Wann Multi-Tenant wahlen

Multi-Tenant-Architektur ist die richtige Wahl, wenn:

• Sie B2B-SaaS fur KMUs bauen. Hohes Volumen, niedrigere Preispunkte und standardisierte Feature-Sets.
• Kosteneffizienz wichtig ist. Sie mussen die Infrastrukturkosten im Verhaltnis zum Umsatz niedrig halten.
• Sie schnelle, einheitliche Updates wollen. Einmal deployen, alle Mandanten bekommen die Verbesserung.
• Ihre Kunden keine dedizierte Infrastruktur verlangen. Die meisten kleinen und mittelstandischen Unternehmen interessiert es nicht, wo ihre Daten liegen, solange sie sicher sind.
• Sie in der Fruhphase sind. Starten Sie Multi-Tenant. Es ist gunstiger und einfacher. Sie konnen spater immer Single-Tenant fur Enterprise-Kunden anbieten.

Wann Single-Tenant wahlen

Single-Tenant-Architektur ergibt Sinn, wenn:

• Sie an Enterprises verkaufen. Grosse Organisationen verlangen oft dedizierte Infrastruktur als Teil ihres Beschaffungsprozesses.
• Compliance es erfordert. Branchen wie Gesundheitswesen (HIPAA), Finanzen (SOX, PCI-DSS) und Behorden haben strenge Datenisolationsanforderungen.
• Kunden Anpassung brauchen. Wenn jeder Kunde unterschiedliche Konfigurationen, Integrationen oder sogar Features benotigt, gibt Ihnen Single-Tenant die Flexibilitat.
• Ihr Preispunkt es tragt. Wenn Sie 5.000 EUR oder mehr pro Monat pro Kunde berechnen, sind die Infrastrukturkosten problemlos gerechtfertigt.
• Datenresidenz eine harte Anforderung ist. Wenn Daten in einem bestimmten Land verbleiben mussen, ist separate Infrastruktur pro Mandant der einfachste Ansatz.

Hybride Ansatze

Sie mussen sich nicht fur nur eines entscheiden. Viele erfolgreiche SaaS-Unternehmen nutzen ein hybrides Modell:

• Multi-Tenant fur Standardstufen. Kostenlose, Starter- und Pro-Kunden teilen sich Infrastruktur. Das halt die Kosten niedrig und lasst Sie skalieren.
• Single-Tenant fur Enterprise. Premium-Kunden bekommen dedizierte Instanzen mit individuellen SLAs, Compliance-Zertifizierungen und dediziertem Support.

Der Anwendungscode ist derselbe. Das Deployment-Modell unterscheidet sich. Das erfordert gute Infrastruktur-Automatisierung, ist aber ein bewahrtes Muster.

Wie man ein hybrides Modell implementiert

1. Die App zunachst als Multi-Tenant bauen. Die gesamte Mandantenisolationslogik bleibt unabhangig vom Deployment-Modell gleich.
2. Infrastructure-as-Code nutzen (Terraform, Pulumi oder CDK), um die Umgebungserstellung zu automatisieren.
3. Eine Provisionierungs-Pipeline erstellen, die eine neue dedizierte Umgebung in Minuten hochfahren kann, nicht in Tagen.
4. Eine einzige Codebasis pflegen. Dasselbe Docker-Image lauft sowohl in geteilten als auch in dedizierten Umgebungen. Konfiguration (nicht Code) bestimmt das Verhalten.

Datenbankstrategien im Detail

Die Datenbank ist der Bereich, in dem Tenancy-Entscheidungen den grossten Impact haben. Hier sind drei bewahrte Strategien.

Strategie 1: Geteilte Tabellen mit tenant_id

Jede Tabelle hat eine tenant_id-Spalte. Alle Abfragen filtern danach.

CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- Immer mit Mandantenkontext abfragen
SELECT * FROM projects WHERE tenant_id = $1;

Am besten fur: Die meisten SaaS-Produkte. Einfach, kosteneffektiv, gut verstanden.

Strategie 2: Schema pro Mandant

Jeder Mandant bekommt sein eigenes PostgreSQL-Schema innerhalb einer geteilten Datenbank. Tabellen haben die gleiche Struktur, aber Daten sind physisch getrennt.

-- Schema fur einen neuen Mandanten erstellen
CREATE SCHEMA tenant_abc123;

-- Tabellen im Schema des Mandanten erstellen
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Suchpfad pro Anfrage setzen
SET search_path TO tenant_abc123, public;

-- Abfragen sind jetzt automatisch eingegrenzt
SELECT * FROM projects;

Am besten fur: Produkte, die starkere Isolation als Zeilenebene brauchen, aber nicht die Kosten separater Datenbanken wollen. Funktioniert gut bis zu einigen Hundert Mandanten.

Strategie 3: Separate Datenbanken

Jeder Mandant bekommt eine dedizierte PostgreSQL-Instanz (oder eine dedizierte Datenbank auf einem geteilten Server).

// Datenbank-Connection-Routing
class TenantDatabaseRouter {
  private connections: Map<string, DatabasePool> = new Map();

  async getConnection(tenantId: string): Promise<DatabasePool> {
    if (this.connections.has(tenantId)) {
      return this.connections.get(tenantId)!;
    }

    const config = await this.loadTenantDbConfig(tenantId);
    const pool = new DatabasePool({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.user,
      password: config.password,
    });

    this.connections.set(tenantId, pool);
    return pool;
  }

  private async loadTenantDbConfig(tenantId: string): Promise<DbConfig> {
    // Datenbankverbindungsdetails des Mandanten nachschlagen
    // aus einem zentralen Konfigurationsspeicher
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Am besten fur: Enterprise-SaaS mit hochwertigen Kunden, strengen Compliance-Anforderungen oder Datenresidenz-Pflichten.

Die Entscheidung treffen

Hier ist ein einfaches Entscheidungs-Framework:

1. Was ist Ihre Zielkundengrosse? KMU deutet auf Multi-Tenant. Enterprise deutet auf Single-Tenant oder Hybrid.
2. Was ist Ihr Preispunkt? Unter 100 EUR/Monat mussen Sie Multi-Tenant sein, um profitabel zu sein. Uber 1.000 EUR/Monat wird Single-Tenant machbar.
3. Was sind die Compliance-Anforderungen? Regulierte Branchen erfordern oft starkere Isolation.
4. Wie viele Mandanten erwarten Sie? Hunderte oder Tausende Mandanten brauchen geteilte Infrastruktur. Zehn bis funfzig grosse Mandanten konnen mit dedizierten Instanzen funktionieren.
5. Was ist die operative Kapazitat Ihres Teams? Single-Tenant erfordert mehr DevOps-Investment. Multi-Tenant ist operativ einfacher.

Wenn Sie unsicher sind, starten Sie mit Multi-Tenant mit einer geteilten Datenbank und Row-Level Security. Es ist die kostengunstigste Option, sicher bei korrekter Implementierung, und halt Ihre Architektur einfach. Sie konnen spater immer eine dedizierte Stufe fur Enterprise-Kunden hinzufugen.

Das Fazit

Es gibt kein universell richtiges Tenancy-Modell. Die richtige Wahl hangt von Ihren Kunden, Ihrer Preisgestaltung, Ihren Compliance-Anforderungen und Ihren operativen Fahigkeiten ab.

Die meisten SaaS-Produkte sollten Multi-Tenant starten. Es ist gunstiger, einfacher und skaliert gut. Wenn Sie nach oben in den Markt gehen und anfangen, an grossere Organisationen zu verkaufen, fugen Sie Single-Tenant-Optionen fur Kunden hinzu, die sie brauchen und entsprechend bezahlen.

Die Architektur sollte dem Geschaft dienen, nicht umgekehrt. Bauen Sie fur die Kunden, die Sie heute haben, und entwerfen Sie mit genug Flexibilitat, um die Kunden zu bedienen, die Sie morgen wollen.

---

Brauchen Sie Hilfe bei der Wahl der richtigen Architektur fur Ihr SaaS-Produkt? Wir haben Multi-Tenant- und Single-Tenant-Systeme branchenubergreifend gebaut. Lassen Sie uns den besten Ansatz fur Ihr Projekt herausfinden.