Multi-tenant-Architektur: die Basis eines skalierbaren SaaS

Wenn Sie ein SaaS bauen, taucht das Wort „multi-tenant“ bald auf, und es ist kein kleiner Fachbegriff: Es ist die Entscheidung, die bestimmt, wie Ihr Produkt skaliert, wie viel der Betrieb kostet und wie sicher die Daten Ihrer Kunden sind. Erklären wir es klar.

Was multi-tenant ist

Multi-tenant (Mehrmandantenfähigkeit) bedeutet, dass eine einzige Instanz Ihrer Anwendung viele Kunden (Tenants) zugleich bedient und dabei die Daten jedes Einzelnen getrennt und privat hält. Es ist wie ein Wohnhaus: eine einzige Struktur, aber jeder Mieter hat seinen abgeschlossenen Raum. Die Alternative, single-tenant, wäre eine komplette Kopie der App pro Kunde: anfangs einfach, aber teuer und im großen Maßstab unbeherrschbar.

Warum es so wichtig ist

Multi-tenant ist es, was das SaaS-Modell rentabel macht: Sie pflegen ein einziges System, launchen Verbesserungen für alle gleichzeitig und nutzen die Infrastruktur effizient. Eine gute multi-tenant-Architektur erlaubt den Sprung von 10 auf 10.000 Kunden, ohne das Produkt neu zu schreiben; eine schlechte erzwingt eine schmerzhafte Neuschreibung genau dann, wenn Sie zu wachsen beginnen.

Die Modelle: wie man die Daten trennt

Es gibt drei Hauptansätze, um die Daten jedes Kunden zu isolieren, mit unterschiedlicher Balance zwischen Kosten, Isolation und Komplexität:

• Gemeinsame Datenbank: alle Kunden in denselben Tabellen, getrennt durch einen Identifikator. Am günstigsten und effizientesten; erfordert große Sorgfalt, um Daten nicht zu vermischen.
• Schema pro Kunde: eine gemeinsame Datenbank mit einem getrennten Schema pro Kunde. Balance zwischen Isolation und Kosten.
• Datenbank pro Kunde: jeder Kunde mit seiner eigenen Datenbank. Maximale Isolation (ideal für sehr sensible Daten), aber teurer im Betrieb.

Datenisolation und Sicherheit

Das größte Risiko eines multi-tenant-SaaS ist, dass ein Kunde die Daten eines anderen sieht. Deshalb ist die Isolation nicht optional: Sie wird in der Datenschicht entworfen und mit Zugriffskontrolle bei jeder Anfrage verstärkt. Ein gutes multi-tenant-Design macht es technisch unmöglich, dass ein Tenant auf die Informationen eines anderen zugreift, und wird genau darauf getestet.

Skalierbarkeit und Kosten

Das gewählte Modell bestimmt Ihre Infrastrukturrechnung über Jahre. Die gemeinsame Datenbank skaliert mit den geringsten Kosten pro Kunde, deshalb ist sie in Volumen-SaaS am verbreitetsten. Die stärker isolierten Modelle kosten mehr pro Kunde, sind aber die richtige Wahl, wenn Sie an regulierte Branchen (Gesundheit, Finanzen) verkaufen, die eine strikte Trennung verlangen.

Wann welches Modell wählen

Es gibt keinen universellen Sieger. Für ein B2C- oder KMU-SaaS mit vielen Kunden ist die gemeinsame Datenbank meist die ideale Wahl. Für ein Enterprise-SaaS mit wenigen großen Kunden und sensiblen Daten lohnt sich die Isolation per Schema oder Datenbank. Wichtig ist, es von Anfang an zu entscheiden, denn die Migration von einem Modell zum anderen mit Kunden in der Produktion ist teuer.

Häufige Fehler beim multi-tenant-Design

Die teuersten Fehler sind meist zwei: das stärker isolierte Modell „für alle Fälle“ zu wählen und die Infrastrukturrechnung unnötig in die Höhe zu treiben, oder das Gegenteil, Daten in einer gemeinsamen Datenbank ohne robuste Isolation zu vermischen und ein Datenleck zwischen Kunden zu riskieren. Der andere klassische Fehler ist, die Entscheidung auf „später“ zu verschieben: das Modell mit Kunden in der Produktion zu wechseln gehört zum Teuersten und Riskantesten überhaupt. Entscheiden Sie früh, mit Ihrem Kundentyp und Ihren Sicherheitsanforderungen auf dem Tisch, und gestalten Sie die Isolation als Anforderung, nicht als Zusatz.

Bei AxiomTech entwerfen wir die multi-tenant-Architektur Ihres SaaS nach Ihrem Kundentyp und Ihren Sicherheitsanforderungen, damit es effizient skaliert und die Daten jedes Kunden stets isoliert sind.