Multi-Tenancy erklärt:Eine Datenbank, 1.000 Kunden

Multi-Tenancy erklärt: Multi-Tenancy heißt, dass mehrere Kunden sich eine Datenbank teilen, aber jeder Kunde nur seine eigenen Daten sehen kann. So bedient ein Solo-Gründer 1.000 Organisationen mit einer einzigen Anwendung, ohne etwas neu zu bauen – und es funktioniert wegen einer Spalte, die von Tag 1 an in jeder Tabelle sein muss: organization_id.

Wenn du ein SaaS mit KI baust, ist das eine der wenigen Architekturentscheidungen, die du später nicht günstig korrigieren kannst. Hier steht, was Multi-Tenancy ist, warum die falsche Wahl Monate kostet und welche genauen Regeln du deiner KI geben musst, damit sie es richtig macht.

Multi-Tenancy erklärt: die Analogie vom Mehrfamilienhaus

Stell dir dein SaaS als Gebäude vor. Jeder Kunde ist ein Mieter (Tenant). Du hast zwei Möglichkeiten.

Du könntest für jeden Kunden ein eigenes Haus bauen. Jedes Haus braucht sein eigenes Fundament, seine eigenen Leitungen und seine eigene Instandhaltung. Zehn Kunden, zehn Häuser. Tausend Kunden, tausend Häuser – und wenn du die Küche modernisieren willst, renovierst du tausend Küchen.

Oder du baust ein einziges Mehrfamilienhaus. Ein Fundament, ein Leitungssystem, ein Wartungsteam. Jeder Mieter hat seine eigene Wohnung, sein eigenes Schloss, seinen eigenen Schlüssel. Niemand kann in die Wohnung des Nachbarn gehen, aber du wartest nur ein Gebäude.

Multi-Tenancy ist das Mehrfamilienhaus. Eine Anwendung, eine Datenbank, ein Deployment – für alle Kunden, wobei jeder nur seine eigenen Daten sieht. Es ist die Standardarchitektur fast jedes SaaS-Produkts, das du nutzt, und sie macht die Wirtschaftlichkeit von SaaS im Solo-Maßstab erst möglich.

Die drei Wege, 1.000 Kunden zu bedienen

Technisch gibt es drei Ansätze. Nur einer davon ergibt für einen Solo-Gründer Sinn:

Die dritte Option ist das, worauf sich die Branche geeinigt hat, und darum geht es in diesem Artikel. Eine Datenbank zu warten. Eine Änderung, wenn du etwas verbesserst. Ein Backup. Und du kannst von 1 auf 10.000 Kunden skalieren, ohne das Schema zu ändern.

Die eine Spalte, die jede Tabelle braucht

Hier ist die goldene Regel: Jede Tabelle, die Kundendaten speichert, muss eine Spalte organization_id haben. Nicht „sollte haben". Nicht „kann man später ergänzen". Muss sie haben, von Tag 1 an.

Du musst keinen Code schreiben, um es zu verstehen. Konzeptionell bekommt jede Zeile in deiner Datenbank ein Etikett, auf dem steht, zu welchem Kunden sie gehört. In der Aufgabentabelle eines Task-Managers trägt „Homepage gestalten" das Etikett von Acme; „Q3-Zahlen prüfen" trägt das von TechStart. Jedes Mal, wenn die Anwendung Daten liest, fragt sie nur nach Zeilen mit dem Etikett des aktuellen Kunden. Jedes Mal, wenn sie Daten schreibt, stempelt sie die neue Zeile mit diesem Etikett. Acme sieht die Aufgaben von Acme. TechStart sieht die von TechStart. Das Etikett ist der Wohnungsschlüssel.

Das wirkt mühsam. Es ist aber auch das Fundament, auf dem alles andere funktioniert – auch die Sicherheitsschicht, die es auf Datenbankebene automatisch durchsetzt und die einen eigenen Artikel verdient (und bekommt).

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

„Aber ich habe gerade nur einen Kunden"

Das höre ich ständig. Das ist der Film, der abläuft, wenn du Multi-Tenancy überspringst:

• Tag 1: Du baust für einen Kunden. Alles funktioniert. Keine Etiketten nötig – alle Daten gehören ohnehin ihm.
• Tag 30: Du gewinnst einen zweiten Kunden. Beide Kunden sehen nun gegenseitig ihre Daten. Panik. Das Etikett nachträglich auf jede Tabelle zu bringen bedeutet etwa drei Wochen Arbeit, Produktionsausfall und verärgerte Kunden.
• Der alternative Film: Du baust von Tag 1 an mit organization_id. An Tag 30 läuft der zweite Kunde einfach. An Tag 300 hast du 100 Kunden und null Datenbankänderungen vorgenommen.

Ein Freund von mir hat sein SaaS ohne Multi-Tenancy gebaut. Als er seinen 10. Kunden erreichte, verbrachte er drei Monate damit, seine gesamte Datenbank neu aufzubauen. Drei Monate ohne neue Features, während die Kunden warteten. Sei nicht dieser Mensch.

Deshalb predige ich auch, die Datenbank zu entwerfen, bevor du promptest: Die Entscheidungen, die an Tag 1 billig sind – eine Spalte, eine Gewohnheit –, werden an Tag 300 brutal teuer.

Die drei Regeln, die es schnell und sicher halten

Regel 1: Beschrifte jede Tabelle, ohne Ausnahme. Sobald in einer Tabelle organization_id fehlt, ist diese Tabelle ein Datenleck, das nur darauf wartet, zu passieren. Mache das beim Briefing deiner KI zu einer festen Anweisung, nicht zu einer Anfrage pro Aufgabe – es ist genau die Art Regel, die zu deinen Entscheidungen auf Architektenebene gehört, denn die KI überspringt sie bereitwillig, wenn du nicht darauf bestehst.

Regel 2: Indexiere das Etikett. Ein Index ist das Telefonbuch der Datenbank – er lässt die Datenbank direkt zu den Zeilen eines Kunden springen, statt jede Zeile zu lesen, um das Etikett zu prüfen. Der Unterschied ist nicht akademisch: Bei 1 Million Zeilen über 1.000 Organisationen dauert eine nicht indexierte Abfrage rund 2.000 Millisekunden. Mit Index dauert dieselbe Abfrage etwa 5. Bitte deine KI, für jede Tabelle, die sie anlegt, einen Index auf organization_id hinzuzufügen.

Regel 3: Vertraue nie dem Browser, wer fragt. Die Identität des Kunden muss aus der Login-Sitzung auf dem Server kommen, nie aus etwas, das der Browser sendet. Wenn ein böswilliger Nutzer deiner App sagen kann „Ich bin Organisation X", kann er die Daten von Organisation X lesen. Der Server weiß, wer eingeloggt ist; das ist die einzige Quelle der Wahrheit.

Drei Regeln. Eine Spalte. Das ist der Unterschied zwischen einer Demo und einem Produkt, das du an deinen zweiten, zehnten und tausendsten Kunden verkaufen kannst.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Häufig gestellte Fragen

Was bedeutet Multi-Tenancy in einfachen Worten?

Mehrere Kunden (Tenants) teilen sich eine Anwendung und eine Datenbank, aber jeder sieht nur seine eigenen Daten. Wie ein Mehrfamilienhaus: ein Gebäude, viele private Wohnungen, ein Schlüssel pro Mieter. Es ist die Standardarchitektur für SaaS-Produkte.

Brauche ich Multi-Tenancy, wenn ich nur einen Kunden habe?

Ja – genau dann ist es billig. Eine Spalte organization_id an Tag 1 hinzuzufügen kostet dich nichts. Sie nachzurüsten, nachdem Kunde zwei da ist, kostet Wochen; ein Gründer, den ich kenne, hat bei Kunde zehn drei Monate mit dem Neuaufbau verbracht. Baue es ab der ersten Tabelle ein.

Kann die KI Multi-Tenancy für mich einrichten, wenn ich nicht programmieren kann?

Ja, wenn du ihr die Regel ausdrücklich gibst: „Jede Tabelle, die Kundendaten speichert, muss eine Spalte organization_id mit Index haben, und jede Abfrage muss danach filtern." KI-Tools folgen diesem Muster zuverlässig, wenn man sie anweist – und überspringen es unvorhersehbar, wenn nicht. Du lieferst die Regel; die KI liefert die Umsetzung.

Ist eine geteilte Datenbank sicher genug für Kundendaten?

Ja, wenn sie richtig gemacht ist. Das Etikett organization_id plus Sicherheit auf Datenbankebene (Row-Level Security, die das Etikett bei jeder Abfrage automatisch durchsetzt) ist, wie praktisch alle modernen SaaS-Produkte Isolation umsetzen – derselbe Ansatz bedient Produkte mit Tausenden Organisationen. Unsicher ist die halb gebaute Variante: geteilte Datenbank, keine Etiketten, keine Durchsetzung.