Mandantentrennung — eingebaut, nicht Eigenbau

Tech-USP: Tenant-Scoping ist Default, nicht Opt-in. Jede Entität ist mandanten-getrennt, solange Ihr nicht explizit Cross-Tenant markiert.

Käufer-Sicht: Eine Instanz hostet beliebig viele Mandanten. Jeder Kunde sieht nur seine eigenen Daten — automatisch, ohne dass Eure Entwickler je eine Filter-Klausel von Hand schreiben.

Highlights

• DB-Zugriff ist immer mandanten-getrennt — keine Raw-Query, die Trennung umgehen kann
• Cross-Tenant-Zugriff ist explizit, nicht implizit
• Mandanten-Auflösung über Header, Cookie, Resolver oder Default — passt für Subdomain-, Path- und Header-basierte Setups
• Anonymous-Access für öffentliche Endpoints mit Mandanten-Auflösung über den Host
• Pro Mandant: eigener Suchindex (Meilisearch), eigene Feature-Toggles, eigene Konfiguration

Architektur-Tiefendoku

• tenant-db-context — ctx.db Scoping, Cross-Tenant-Eskalation
• permissions — Roles + Ownership-Filter
• core-tenant — Tenant-Stammdaten + Membership
• scaling — Multi-Tenant-Skalierung (DB-shared vs DB-per-tenant)

Wo das im Pitch landet

• DACH-Sales: Top-Argument #1 — jedes interne Tool braucht Mandantentrennung sobald mehr als eine Abteilung es nutzt
• Indie-Hacker: Explizites Argument unter „Backend-Pain” — Mandantentrennung ist die häufigste Bug-Quelle in B2B-SaaS