Was ist Multi-Tenancy?
Definition und Architektur-Modelle

Direkte Antwort

Multi-Tenancy in drei Sätzen

Multi-Tenancy (auf Deutsch: Mehrkundenfähigkeit) ist die Architektur, bei der eine einzelne Software-Instanz mehrere unabhängige Kunden („Tenants“) bedient, ohne dass diese sich gegenseitig sehen oder beeinflussen. Jeder Tenant hat den Eindruck, eine eigene, dedizierte Anwendung zu nutzen — technisch teilen sich alle aber Infrastruktur und Code.

Das Gegenteil ist Single-Tenancy: jeder Kunde erhält seine eigene App-Instanz und oft auch eine eigene Datenbank. Mehrkundenfähigkeit ist wirtschaftlicher, aber in Architektur und Sicherheit anspruchsvoller.

Modell 1

Shared Database, Shared Schema (100% Pooling)

Aufbau: Alle Tenants teilen sich exakt eine Datenbank und ein Schema. Jede Tabelle hat eine tenant_id-Spalte.

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  tenant_id UUID NOT NULL,  -- Welcher Tenant gehört dieser Nutzer?
  email VARCHAR NOT NULL,
  name VARCHAR NOT NULL,
  created_at TIMESTAMP DEFAULT NOW(),
  UNIQUE(tenant_id, email)   -- Email ist pro Tenant unique
);

CREATE INDEX idx_users_tenant ON users(tenant_id);

Sicherheit: Bei Shared Schema braucht es eine konsequente Isolation auf Datenbank- oder Zugriffsschicht, zum Beispiel Postgres RLS oder Supabase Row-Level Policies.

CREATE POLICY "Users can only see their own tenant's data"
ON users FOR SELECT
USING (tenant_id = auth.uid()); -- Vereinfacht; in Realität: JWT-Tenant-ID extrahieren

Modell 3

Database-per-Tenant (vollständige Isolation)

Aufbau: Jeder Tenant bekommt seine eigene Datenbank (und idealerweise: eigene Server, eigene Backups).

Tenant A  → PostgreSQL Instance tenant-a.internal → Backup tenant-a-backup
Tenant B  → PostgreSQL Instance tenant-b.internal → Backup tenant-b-backup
Tenant C  → PostgreSQL Instance tenant-c.internal → Backup tenant-c-backup

Code-Seite:

async function getTenantDbConnection(tenantId) {
  const dbConfig = await getTenantConfig(tenantId);
  return new Pool({
    connectionString: dbConfig.connectionString // z.B. postgres://user:pass@tenant-a.internal/db
  });
}

async function getUsersForTenant(tenantId) {
  const pool = await getTenantDbConnection(tenantId);
  const result = await pool.query(`SELECT * FROM users`);
  return result.rows;
}

In der Praxis

Nachträgliche Multi-Tenancy mit Postgres-RLS

Du hast einen Prototyp mit Lovable gebaut. Users-Tabelle, keine Multi-Tenancy. Jetzt kommen Kunden.

Schritt 1: Migriere die Tabelle

-- Alte Tabelle
ALTER TABLE users ADD COLUMN tenant_id UUID NOT NULL DEFAULT gen_random_uuid();

-- Künftig: Jeder User-Insert kennt tenant_id
-- INSERT INTO users (tenant_id, email, name) VALUES ('tenant-123', 'alice@co.com', 'Alice');

Schritt 2: Aktiviere Row-Level Security (Postgres RLS)

ALTER TABLE users ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users see only their tenant's data"
ON users FOR SELECT
USING (tenant_id = current_setting('app.tenant_id')::uuid);

CREATE POLICY "Users insert only for their tenant"
ON users FOR INSERT
WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid);

Schritt 3: Code passt Tenant-Context

// In Next.js API-Route
export async function GET(req) {
  const tenantId = req.headers['x-tenant-id']; // Oder aus JWT

  // Supabase Client mit Tenant-Context
  const { data, error } = await supabase
    .from('users')
    .select('*')
    .eq('tenant_id', tenantId);

  return Response.json(data);
}

Schritt 4: Test

• Login als User von Tenant A, prüfe: Nur Tenant A’s Daten sichtbar.
• Versuche, manuell tenant_id im Request zu ändern → RLS blockiert.

FAQ

Häufige Fragen zu Multi-Tenancy