Du baust ein B2B-Produkt. Wie isolierst du die Daten eines Kunden von denen eines anderen?

Die drei Optionen sind ein gemeinsames Schema mit einer Tenant-id-Spalte, ein Schema pro Mandant und eine Datenbank pro Mandant, was operative Einfachheit gegen Isolation tauscht. Ein gemeinsames Schema skaliert am besten und kostet am wenigsten, verlangt aber, dass der Tenant-Filter strukturell durchgesetzt wird, zum Beispiel mit Row Level Security oder einer Datenschicht, die ihn immer anwendet. Eine Datenbank pro Mandant gibt die stärkste Isolation und die einfachste Wiederherstellung pro Kunde, zu echten operativen Kosten.

Mein Default ist ein gemeinsames Schema mit einer Tenant-id auf jeder Tabelle, weil es am billigsten zu betreiben ist und das Onboarding eines Kunden ein Insert statt eines Provisioning-Jobs ist. Die Gefahr liegt auf der Hand, eine fehlende where-Klausel leakt Daten zwischen Kunden, das überlasse ich also nie der Disziplin. Ich nutze Row Level Security mit dem Mandanten aus der authentifizierten Session, sodass selbst eine handgeschriebene Query nichts außerhalb des Mandanten liefert, und ich baue Tests, die absichtlich versuchen, die Zeilen eines anderen Mandanten zu lesen. Auf ein Schema oder eine Datenbank pro Mandant wechsle ich, wenn es einen echten Treiber gibt: ein Kunde mit vertraglicher Anforderung an den Datenstandort, eine Handvoll Enterprise-Accounts, die groß genug für eigene Last sind, oder ein Compliance-Regime, das nachweisbare Trennung will. Die Kosten unterschätzen Leute: eine Migration läuft jetzt über jedes Schema, Connection Pooling wird schwieriger, und du brauchst Automatisierung für Provisioning und Restore pro Mandant. Noisy Neighbors musste ich außerdem separat lösen, mit Rate Limits pro Mandant, denn Datenisolation ist keine Kapazitätsisolation.