Warum wir für Enterprise-RAG keine eigene Vektordatenbank nutzen, sondern alles auf PostgreSQL/pgvector mit Row-Level-Security zwingen

Das eigentliche Problem ist nicht die Suche

Jede RAG-Demo funktioniert mit einer Vektordatenbank. Die Frage, an der Projekte im Unternehmen scheitern, lautet anders: Darf die Person, die gerade fragt, diesen Absatz überhaupt sehen? Und: Können wir das in zwei Jahren noch beweisen?

Mit einer separaten Vektordatenbank entstehen zwei Datenhaltungen mit zwei Rechtemodellen. Dokumente, Versionen und Freigaben leben in PostgreSQL oder im DMS, die Embeddings woanders. Die Synchronisation wird zur Sicherheitsgrenze – und genau diese Grenze ist in keinem Datenmodell sichtbar.

Die Entscheidung

ATF Search speichert Chunks, Embeddings, Volltextindex, Dokumentversionen und Zugriffsrechte in einer PostgreSQL-Instanz mit pgvector. Die Rechteprüfung ist Teil derselben SQL-Abfrage wie die Vektorsuche. Es gibt keinen Zustand, in dem ein Treffer zuerst geladen und danach “weggefiltert” wird.

-- schematisch: Ähnlichkeit, Volltext und Recht in einer Abfrage
SELECT id, content, 1 - (embedding <=> $1) AS score
FROM chunks
WHERE collection = $2
  AND (allowed_users @> ARRAY[$3] OR allowed_groups && $4)
ORDER BY embedding <=> $1
LIMIT 20;

Die Identität ($3, $4) stammt aus dem verifizierten Token – nie aus einem Feld, das der Client mitschickt. Ein Modell oder ein Frontend kann sich keine Rechte erschreiben.

Für mandantenbezogene Daten der Runtime – Ausführungen, Kosten, Provider-Schlüssel, PII-Vault-Einträge – kommt Row-Level-Security dazu. Jede Transaktion setzt app.current_tenant transaktionslokal; die Policy tenant_isolation ist auf den Tabellen erzwungen (FORCE ROW LEVEL SECURITY). Selbst eine Abfrage, der ein WHERE tenant_id = … fehlt, liefert dann keine fremden Zeilen.

cd apps/runtime
bun run scripts/cli.ts rls-setup            # Plan anzeigen (Dry-Run)
bun run scripts/cli.ts rls-setup --confirm  # Rollen, Grants, Policies anlegen
TENANT_RLS_ENABLED=true TENANT_RLS_REQUIRED=true

Querschnittliche Operator-Sichten laufen über eine eigene Verbindung mit eigener Rolle (DATABASE_OPERATOR_URL). Der Produktions-Gate verweigert den Start, wenn RLS aktiv ist, diese Trennung aber fehlt.

Was man dafür bekommt

• Eine Wahrheit für Rechte. Wer im DMS ein Dokument nicht sehen darf, bekommt es auch über die KI nicht. Es gibt keine zweite ACL, die veralten kann.
• Hybrid ohne Zusatzsystem. Dichte Vektoren und PostgreSQL-Volltext werden per Reciprocal Rank Fusion kombiniert, optional mit SPLADE-Sparse-Vektoren und Reranking.
• Transaktionen über Text und Vektor. Eine neue Dokumentversion wird atomar umgeschaltet. Es gibt kein Zeitfenster, in dem alte Embeddings auf neuen Text zeigen.
• Löschung, die man belegen kann. Ein DSGVO-Löschauftrag trifft Text, Embedding und Metadaten in derselben Datenbank – und endet in einem signierten Beleg.
• Betrieb, den Ihre IT schon kann. Backup, Point-in-Time-Recovery, Monitoring, Verschlüsselung at rest: alles PostgreSQL-Standard.

Was es kostet – ehrlich

pgvector ist bei Milliarden Vektoren nicht die schnellste Engine der Welt. ATF begegnet dem mit Halbpräzision (halfvec), Quantisierung, begrenzten Kandidatenmengen und Score-Keyset-Pagination. Für die typische Unternehmensgröße – Millionen Chunks, nicht Milliarden – ist das mehr als ausreichend. Wer tatsächlich Web-Scale braucht, hat in der Regel auch ein anderes Rechtemodell.

RLS ist in ATF ein bewusster Onboarding-Schritt und kein stiller Default: Die Rollen und Verbindungsdaten gehören der Betreiberin. Die anwendungsseitige Mandantenfilterung bleibt Pflicht – RLS ist Verteidigung in der Tiefe, keine Erlaubnis, Prädikate wegzulassen.

Die Konsequenz für Ihr Projekt

Wenn ein Prüfer fragt, warum Mitarbeiterin A eine Antwort aus Dokument B bekommen hat, zeigen wir eine SQL-Policy und einen Trace – keine Synchronisationslogik zwischen zwei Systemen.