Multi-Organisation: Datenisolation auf Datenbankebene

Unsere Plattform ist von Tag eins als Multi-Org-System gebaut. Wir starteten mit einem Kunden, planten für hundert. Jede Organisation hat ihre eigenen Daten, und diese Daten sind auf Datenbankebene isoliert -- nicht nur auf Anwendungsebene.

Warum Anwendungs-Level Isolation nicht reicht

Viele SaaS-Plattformen implementieren Mandantentrennung über WHERE-Clauses in der Anwendungslogik. Das funktioniert, ist aber fehleranfaellig: Ein vergessener Filter, ein falsch konfigurierter Query, und Daten eines Mandanten sind für einen anderen sichtbar.

Row Level Security als Fundament

Wir nutzen Row Level Security (RLS) auf PostgreSQL-Ebene. Jede Zeile in der Datenbank gehoert zu einer Organisation, und die Datenbank selbst erzwingt, dass Queries nur Zeilen der eigenen Organisation zurueckgeben. Das ist unabhaengig von der Anwendungslogik und kann nicht versehentlich umgangen werden.

Rollenmodell

Vier Rollen: Owner mit vollem Zugriff, Read+Write für aktive Mitarbeiter, Read-only für Betrachter und Superuser für plattformweite Administration. Jede Rolle wird über die API und die UI konsistent durchgesetzt.

Shared-Nothing Architektur

Die Isolation geht über die Datenbank hinaus: Jede Organisation hat eigene Storage-Buckets, eigene API-Keys und eigene Webhook-Konfigurationen. Es gibt keine gemeinsam genutzten Ressourcen zwischen Organisationen.

Lessons Learned

RLS ist schwerer zu debuggen als WHERE-Clauses. Aber jede investierte Stunde lohnt sich. Multi-Tenancy nachträglich einzubauen kostet zehnmal mehr als es von Anfang an mitzudenken. In unseren Benchmarks liegt der RLS-Overhead bei unter 2ms pro Query.