Large Language Models (LLMs) sind leistungsfähig, arbeiten jedoch ohne Echtzeitzugriff auf Ihre Daten. Sie haben Schwierigkeiten mit privaten, sich ändernden oder domänenspezifischen Informationen und neigen zu Halluzinationen, wenn ihre Trainingsdaten unvollständig sind. Retrieval-Augmented Generation (RAG) begegnet diesem Problem, indem zur Anfragezeit relevanter Kontext aus eine externen Datenquellen abgerufen und dem Modell zur Verfügung gestellt wird.

Um eine schnelle und kontextbewusste Retrieval-Funktion auf Basis einer Nutzeranfrage zu ermöglichen, setzen die meisten Systeme auf semantische Suche über Embeddings. Dabei werden Dokumente in kleinere Chunks aufgeteilt, in einen hochdimensionalen Vektorraum eingebettet und dasselbe mit der Nutzeranfrage durchgeführt. Eine Ähnlichkeitssuche identifiziert anschließend die nächstgelegenen Treffer. Semantische Suche allein weist jedoch Lücken auf: Seltene Begriffe, exakte Phrasen oder Code-Snippets lassen sich häufig besser über keywordbasierte Suche abdecken. Aus diesem Grund nutzen viele produktive Setups einen hybriden Ansatz, der beide Methoden kombiniert

Eine gängige Wahl sind gemanagte Vektor-Datenbanken wie Pinecone, Weaviate oder Chroma. Diese funktionieren gut, bringen jedoch zusätzlichen operativen Aufwand mit sich: mehr Infrastruktur, mehr APIs, die verwaltet werden müssen, und höhere Kosten. Für viele Projekte gibt es eine einfachere Alternative: PostgreSQL kann in Kombination mit der pgvector-Erweiterung als Vector Store dienen und semantische Suche direkt unterstützen – während gleichzeitig keywordbasierte Suche über die integrierten Full-Text-Search-(FTS)-Funktionen möglich ist. Da PostgreSQL in vielen Backends ohnehin die primäre Datenbank ist, bietet dieser Ansatz eine komfortable Möglichkeit, alles an einem Ort zu halten und dennoch hybride Suche effizient umzusetzen.

Dieser Beitrag ist ein praxisorientierter Leitfaden und deckt folgende drei Bereiche ab:

Vektorsuche mit pgvector
Keyword-basierte Suche mit Full Text Search
Row-Level Security (RLS) zur Einschränkung des Zugriffs auf private Daten

Am Ende verfügen Sie über ein funktionierendes, auf PostgreSQL basierendes Retrieval-Setup, das ein RAG-System unterstützen kann, ohne eine weitere Infrastrukturkomponente hinzufügen zu müssen.

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Vektorsuche mit pgvector

pgvector erweitert PostgreSQL um native Vektortypen und Nearest-Neighbor-Suche, sodass Embeddings direkt neben relationalen Daten gespeichert und mit SQL abgefragt werden können. Um pgvector zu verwenden, muss die Erweiterung einmal pro Datenbank aktiviert werden:

CREATE EXTENSION IF NOT EXISTS vector;

pgvector unterstützt mehrere Vektortypen mit unterschiedlichen Limits:

VECTOR – bis zu 2.000 Dimensionen
HALFVEC – bis zu 4.000 Dimensionen
BIT – bis zu 64.000 Dimensionen
SPARSEVEC – bis zu 1.000 Nicht-Null-Elemente

Für Embedding-Modelle mit einer Dimensionalität unter 2k (z. B. OpenAI text-embedding-3-small) ist VECTOR die Standardwahl. Für Modelle, die über 2k Dimensionen hinausgehen (z. B. OpenAI text-embedding-3-large), ist HALFVEC eine naheliegende Option, da es den Speicherbedarf ungefähr halbiert.

Einrichten einer VECTOR-Spalte für Embeddings

Für jede Tabelle können eine oder mehrere Vektorspalten hinzugefügt werden. Wenn die Dimensionalität der Embeddings bekannt ist, sollte sie explizit angegeben werden, da dies frühe Prüfungen und eine bessere Query-Planung ermöglicht. Zum Beispiel:

CREATE TABLE documents (
id
titel
        BI GSERIAL PRIMÄRSCHLÜSSEL,
     TEXT,
Inhalt TEXT,
einbettung VECTOR(1536)
);

PostgreSQL erstellt Embeddings nicht selbst. Diese müssen mit einem Embedding-Modell berechnet und anschließend zusammen mit den bestehenden Daten in der Datenbank gespeichert werden.

Ausführen einer Vektorsuche

Beim Abfragen der Datenbank wird zunächst ein Embedding für die Anfrage berechnet – mit demselben Modell, das auch beim Speichern der Dokument-Embeddings verwendet wurde. Dadurch kann der Anfragevektor mit den Vektoren in der Datenbank verglichen werden, um die relevantesten Treffer zu ermitteln.

Um zu messen, wie nah zwei Vektoren in diesem Raum beieinanderliegen, werden üblicherweise verschiedene Ähnlichkeitsmetriken verwendet:

L2-Distanz: <->
Inneres Produkt (negativ, für aufsteigende Sortierung): <#>
Cosine Distanz: <=>
L1-Abstand: <+>
Bit-Vektoren: Hamming <~> und Jaccard <%>

Die Cosine Distanz ist eine gute Standardwahl, da sie die Ähnlichkeit der Richtung und nicht die reine Magnitude misst. Die meisten Embedding-Modelle erzeugen Vektoren, bei denen die Richtung die Bedeutung kodiert, und viele Anbieter normalisieren die Vektoren auf Einheitslänge. Unter Normalisierung liefern Cosine Distanz, Inneres Produkt und L2-Distanz identische Rankings, wobei Cosine Distance und Inneres Produkt in der Regel schneller zu berechnen sind und weniger empfindlich auf Unterschiede in der Vektorskala reagieren.

Beispielabfrage:

SELECT id, title
FROM dokumente
ORDER BY embedding &lt;=&gt; $1 -- $1 ist ein 1536-dim Vektorliteral wie '[...]'
LIMIT 10;

Indexierung für Performance

Exakte Vektorsuche bietet perfekte Recall-Werte, skaliert jedoch schlecht. Bei großen Datensätzen steigt die Latenz, da jeder Vektor vollständig gescannt werden muss. Um die Latenz zu reduzieren, wird ein Approximate-Nearest-Neighbor-(ANN)-Index hinzugefügt. pgvector unterstützt zwei ANN-Indextypen: IVFFlat (inverted file with flat compression) und HNSW (hierarchical navigable small world).

IVFFlat partitioniert den Vektorraum in Cluster (sogenannte Lists). Zur Query-Zeit werden nur die ähnlichsten Lists durchsucht. Der Index lässt sich schnell aufbauen und benötigt vergleichsweise wenig Speicher, erreicht jedoch einen geringeren Recall als HNSW. Der Index sollte nach dem Laden repräsentativer Daten erstellt werden. Die Anzahl der Lists wird beim Erstellen des Indexes festgelegt, und über ivfflat.probes – das steuert, wie viele dieser Cluster pro Anfrage durchsucht werden – kann pro Query ein Kompromiss zwischen Recall und Geschwindigkeit eingestellt werden.

CREATE INDEX ON documents 
USING ivfflat (embedding halfvec_cosine_ops) WITH (lists = 100); -- per-query recall/speed trade-off 
SET ivfflat.probes = 10;

Faustregeln: Beginnen Sie mit lists = rows / 1000 bis zu 1 Mio. Zeilen und mit sqrt(rows) darüber hinaus; setzen Sie probes ≈ sqrt(lists).

HNSW erstellt eine mehrschichtige Graphstruktur, in der jeder Vektor mit mehreren Nachbarn verbunden ist. Anfragen navigieren von groben oberen Ebenen zu detaillierteren unteren Ebenen, was schnelle Lookups bei gleichzeitig hohem Recall ermöglicht. HNSW eignet sich besonders für leseintensive Workloads, benötigt jedoch mehr Speicher und längere Build-Zeiten als IVFFlat. Ein separater Trainingsschritt ist nicht erforderlich.

Die Qualität des Indexes und der Ressourcenverbrauch werden über zwei Parameter zur Build-Zeit gesteuert

m: Anzahl der Verbindungen, die jeder Knoten hält. Höhere Werte verbessern den Recall, erhöhen jedoch den Speicherbedarf.
ef_construction: Wie breit während des Builds nach Nachbarn gesucht wird. Höhere Werte verbessern die Graphqualität, verlangsamen jedoch die Indexerstellung.

Zur Abfragezeit werden folgender Parameter angepasst:

hnsw.ef_search: Anzahl der Kandidaten-Nachbarn, die untersucht werden. Höhere Werte erhöhen den Recall, verlangsamen jedoch die Abfrage.

CREATE INDEX ON documents
USING hnsw (embedding halfvec_cosine_ops)
WITH (m = 16, ef_construction = 64);

Welche Option ist die richtige? Verwenden Sie HNSW, wenn Sie den bestmöglichen Recall und die geringste Latenz erzielen möchten und ausreichend Speicher zur Verfügung steht. Verwenden Sie IVFFlat, wenn schnellere Build-Zeiten oder ein geringerer Speicherverbrauch wichtiger sind. Bei beiden Indextypen sollten Sie in Ihren Queries stets ORDER BY … LIMIT verwenden, damit der Query Planner den Index nutzen kann.

Keywordbasierte Suche mit Full Text Search (FTS)

Nachdem die Vektorsuche eingerichtet ist, kann die keywordbasierte Retrieval-Funktionalität mithilfe der nativen Full Text Search (FTS) von PostgreSQL ergänzt werden. FTS eignet sich besonders gut für exakte Begriffe, seltene Wörter oder Code-Snippets und ist damit eine sinnvolle Ergänzung zu Embeddings in einem hybriden Such-Setup.

Einrichten einer TSVECTOR-Spalte für durchsuchbaren Text

PostgreSQL speichert durchsuchbaren Text in einem TSVECTOR, der normalisierte Lexeme sowie optional Positionsinformationen enthält. Zum Beispiel:

„Lernen Sie die Verwendung von tsvector und tsquery“ → ‚lernen‘:1 ‚verwenden‘:4 ‚tsvector‘:5 ‚tsquery‘:7

Die Funktionen zum Erzeugen und Abfragen dieser Vektoren sind bereits integriert. Um eine Neuberechnung bei jeder Anfrage zu vermeiden, sollte der TSVECTOR vorab berechnet und in der Tabelle gespeichert werden. Eine generierte, gespeicherte Spalte hält ihn dabei automatisch synchron.

ALTER TABLE articles
ADD COLUMN search_vector tsvector
GENEREATED ALWAYS AS (
to_tsvector('simple', coalesce(title, '') || ' ' || coalesce(content, ''))
) STORED;

Tokenization-Konfiguration

Das obige Beispiel verwendet die Text-Search-Konfiguration simple (keine Stemming- oder Stopword-Entfernung), um den TSVECTOR zu erzeugen. PostgreSQL bietet außerdem sprachspezifische Analyzer (z. B. english, german usw.), die Stemming und Stopword-Removal für die jeweilige Sprache durchführen.

Um alle unterstützten Sprachen aufzulisten, führen Sie Folgendes aus:

SELECT cfgname FROM pg_ts_config;

Für mehrsprachige Daten kann zusätzlich eine sprachspezifische Spalte pro Zeile gespeichert werden, und to_tsvector(ts_config, text) kann entsprechend dynamisch aufgerufen werden.

Gewichtung

PostgreSQL unterstützt außerdem die unterschiedliche Gewichtung von Feldern (z. B. Titel > Textkörper) über gewichtete Vektoren:

ALTER TABLE films
ADD COLUMN search_vector tsvector
GENERATED ALWAYS AS (
setweight(to_tsvector('english', title), 'A') ||
setweight(to_tsvector('english', description), 'B')
) STORED;

Das von PostgreSQL standardmäßig verwendete Gewichtungs-Array ist {D=0.1, C=0.2, B=0.4, A=1.0}, kann jedoch zur Query-Zeit angepasst werden.

Indexierung

PostgreSQL unterstützt zwei Indextypen für Full Text Search: GIN (Generalized Inverted Index) und GiST (Generalized Search Tree).

GIN speichert einen echten invertierten Index: Für jedes Lexem wird eine Liste von Dokumentreferenzen (und optional Positionsinformationen) vorgehalten. Dadurch sind Containment-Checks – also die Frage, welche Dokumente ein bestimmtes Keyword enthalten – schnell und exakt. Die Kehrseite sind ein größerer Index auf der Festplatte sowie langsamere Schreibvorgänge, da Updates diese Posting-Listen pflegen müssen. Für leseintensive Workloads ist das in der Regel akzeptabel, weshalb GIN die Standardwahl für die meisten Textsuche-Szenarien darstellt.

GiST funktioniert anders. Anstatt vollständige Posting-Listen zu speichern, wird jeder tsvector in eine kleine Bitmaske, eine sogenannte Signature, komprimiert. Diese Signaturen fassen zusammen, welche Lexeme in einem Dokument vorkommen, sind jedoch nicht vollkommen präzise. Da unterschiedliche Dokumente dasselbe Bitmuster erzeugen können, kann GiST Zeilen zurückliefern, die nur potenziell passen. PostgreSQL muss in diesem Fall den zugrunde liegenden tsvector erneut prüfen. Der Vorteil ist ein kleinerer Index, der sich schneller erstellen lässt und günstiger in der Aktualisierung ist. Der Nachteil sind gelegentliche False Positives und langsamere komplexe Abfragen.

Welche Option ist die richtige? Wählen Sie GIN, wenn Sie schnelle und präzise Textsuche benötigen und leicht langsamere Indexpflege akzeptieren können. Wählen Sie GiST, wenn Sie viele Schreibvorgänge, häufige Updates oder begrenzten Speicher haben und einen zusätzlichen Recheck-Schritt tolerieren können.

Beispiel:

CREATE INDEX idx_products_search_vector_gin ON products USING GIN (search_vector);
CREATE INDEX idx_products_search_vector_gist ON products USING GIST (search_vector gist_tsvector_ops);

Ausführen einer Full-Text-Suche

Um eine Full-Text-Suche in PostgreSQL auszuführen, wird eine rohe Textanfrage zunächst in das TSQUERY-Format umgewandelt. Ein TSQUERY ist die Query-Repräsentation, die PostgreSQL verwendet, um gegen TSVECTOR-Spalten zu matchen – ähnlich wie ein Embedding-Vektor zur Abfrage eines Vector-Index genutzt wird. Das TSQUERY definiert die Suchbegriffe und die logische Verknüpfung, und PostgreSQL prüft damit, welche Dokumente passen.

Die Umwandlung der Eingabe in ein TSQUERY ist aufwendiger als bei der Vektorsuche. Bei Embeddings wird ein Vektor einmal berechnet und anschließend damit gesucht. Bei der keywordbasierten Suche muss entschieden werden, wie eine natürliche Sprachabfrage in ein sinnvolles TSQUERY überführt wird. Rohanfragen von Nutzern oder von einem LLM in einem RAG-System sind in der Regel nicht für Keyword-Suche optimiert.

Die einfachste Umwandlung ist plainto_tsquery. Diese Funktion normalisiert den Text, entfernt Stopwords und lemmatisiert Begriffe, erzeugt jedoch immer eine AND-Abfrage. Alle Terme müssen im Dokument vorkommen, was in der Praxis häufig zu restriktiv ist.

SELECT plainto_tsquery('english', 'deep learning models'); -- 'deep' &amp; 'learn' &amp; 'model'

Wenn ein höherer Recall erforderlich ist, gibt es zwei Alternativen:

Post Processing: Verbessern Sie die Anfrage vor dem Aufruf von FTS. Dabei können eigene Heuristiken angewendet oder ein LLM genutzt werden, um die Query zu formen (z. B. wenn es als Tool eingesetzt wird). PostgreSQL stellt mit websearch_to_tsquery eine Funktion bereit, die eine Google-ähnliche Syntax akzeptiert und bei fehlerhafter Eingabe keine Errors wirft. Dies ist besonders nützlich, wenn die Query bereits vorverarbeitet wurde.
AND-Abfrage in OR umwandeln: Erzeugen Sie das TSQUERY zunächst mit plainto_tsquery (wie oben gezeigt), um von Parsing und Normalisierung zu profitieren, und ersetzen Sie anschließend & durch |. Dieser kleine „Hack“ erweitert die Treffermenge ohne zusätzliche Latenz, ohne LLM-Aufrufe und ohne eigene Heuristiken, sollte jedoch mit Vorsicht eingesetzt werden. OR-Abfragen können sehr schnell zu breit werden, insbesondere wenn die Eingabe Begriffe enthält, die nicht als Stopwords entfernt werden. Im Extremfall matchen nahezu alle Dokumente, wodurch der Filter-Schritt an Wert verliert. Es ist eine schnelle Möglichkeit, den Recall zu erhöhen, kann die Filterwirkung jedoch deutlich schwächen.

Mit dem berechneten TSQUERY läuft eine Full-Text-Suche in zwei Schritten ab. Zunächst werden die Zeilen mithilfe des TSQUERY und des @@-Operators gefiltert, was vom FTS-Index profitiert. Dieser Schritt bestimmt, welche Dokumente überhaupt matchen. Anschließend werden die passenden Zeilen nach Relevanz gerankt. Ranking ist langsamer als indexbasiertes Filtern, weshalb es – obwohl der erste Schritt technisch optional ist – empfohlen wird, die Treffermenge klein zu halten, um die Latenz beim Ranking zu minimieren.

PostgreSQL stellt zwei Funktionen zur Berechnung eines Relevanz-Scores bereit: ts_rank und ts_rank_cd. Beide nehmen einen TSVECTOR (Dokument) und ein TSQUERY (Anfrage) entgegen und liefern einen numerischen Score zurück, wobei höhere Werte eine bessere Übereinstimmung bedeuten.

ts_rank bewertet Dokumente auf Basis der Termfrequenz und optionaler Gewichtungen. Häufigeres Vorkommen von Suchbegriffen erhöht den Score, jedoch mit abnehmendem Grenznutzen. Sehr häufige Terme werden abgewertet, sodass sie das Ranking nicht dominieren.

ts_rank_cd enthält die gesamte Logik von ts_rank, ergänzt diese jedoch um Cover Density. Dabei wird berücksichtigt, wie nah die Suchbegriffe beieinander im Text auftreten. Dokumente, in denen die Begriffe in einem engen Kontext erscheinen, erhalten einen höheren Score als solche, in denen sie weit auseinanderliegen. Dies verbessert das Ranking insbesondere bei Mehrwortanfragen, da eine enge Häufung meist auf einen relevanteren Kontext hindeutet. Die zusätzliche Logik macht ts_rank_cd langsamer, da Positionsdaten ausgewertet werden müssen. Bei kurzen Dokumenten oder Einwortanfragen ist der Unterschied gering, bei längeren Dokumenten oder Mehrwortanfragen liefert ts_rank_cd in der Regel bessere Rankings.

Beide Funktionen unterstützen eine Normalisierungs-Bitmaske, um rohe Scores anzupassen. Normalisierung kann eine Verzerrung zugunsten langer Dokumente reduzieren und Scores in vergleichbare Bereiche skalieren. Bit 1 teilt durch 1 + log(document_length) und Bit 2 durch die Dokumentlänge, was jeweils den Längeneffekt reduziert. Die Bits 4 und 8 berücksichtigen die Anzahl eindeutiger Terme für die Skalierung. Bit 32 wird in der Praxis häufig verwendet und transformiert Scores zu score / (score + 1), wodurch Werte zwischen 0 und 1 entstehen.

Zusammengefasst kombiniert eine typische Full-Text-Suche das Filtern mit @@ und das Ranking mit ts_rank oder ts_rank_cd. Der Filter nutzt den FTS-Index, um Kandidaten schnell zu selektieren, und das Ranking ordnet anschließend nur diese Treffer. Ein Beispiel könnte wie folgt aussehen:

SELECT id, title, ts_rank_cd(search_vector, query, 32) AS score
FROM products
WHERE search_vector @@ query
ORDER BY score DESC
LIMIT 10;

Hybrides Retrieval: Kombination von pgvector und FTS

Nachdem sowohl Vektorsuche als auch keywordbasierte Suche eingerichtet sind, können beide Verfahren kombiniert werden, um die Ergebnisqualität zu verbessern. Hybride Suche vereint semantische Treffer aus pgvector mit Keyword-Treffern aus der Full Text Search. Dazu werden zwei unabhängige Abfragen ausgeführt – eine Vektorsuche und eine FTS – und die Ergebnisse anschließend zusammengeführt. Beide Abfragen können parallel ausgeführt werden.

Reciprocal Rank Fusion (RRF) kombiniert die beiden Ergebnislisten, indem jedem Dokument ein Score auf Basis seiner Rangposition in den einzelnen Listen zugewiesen und diese Beiträge aufsummiert werden. RRF ist in vielen Retrieval-Setups beliebt, da es einfach, rangbasiert und robust gegenüber Ausreißern ist.

Dabei gilt:

r = Rangposition des Dokuments d in einer Ergebnisliste (1 = bester Rang)
R_d = Menge der Rangpositionen von d über alle Listen hinweg
k = Konstante zur Glättung des Beitrags niedriger gerankter Ergebnisse

Der Wert von k wird üblicherweise auf 60 gesetzt, basierend auf empirischen Auswertungen in der Information-Retrieval-Literatur, bei denen dieser Wert eine stabile Leistung über alle Benchmarks hinweg ohne Anpassung ergab. Größere Werte verringern den Einfluss von Ergebnissen am Ende der Rangliste und stellen sicher, dass die am besten bewerteten Dokumente die fusionierte Bewertung dominieren.

Insgesamt erspart die RRF die Kalibrierung oder Normalisierung der Ergebnisse verschiedener Suchmethoden. Sie ist ein praktischer Standard bei der Kombination von Vektor- und Stichwortsuche.

Row-Level Security (RLS)

Beim Einsatz von PostgreSQL als Grundlage für ein RAG-System werden häufig nutzerspezifische Daten gemeinsam mit geteilten Inhalten gespeichert. Eine reine Vektorsuche garantiert dabei keine Isolation: Ohne zusätzliche Regeln können Embeddings und Textzeilen verschiedener Nutzer in den Ergebnissen auftauchen. Um Datenlecks zwischen Nutzern zu verhindern und sicherzustellen, dass jede Anfrage nur Daten zurückliefert, die der aufrufenden Partei zustehen, wird Zugriffskontrolle auf Tabellenebene durchgesetzt.

Row-Level Security (RLS) ist ein Feature von PostgreSQL, das eine fein granulare Kontrolle darüber ermöglicht, auf welche Zeilen ein Benutzer oder eine Rolle zugreifen oder welche sie verändern darf. RLS erzwingt Einschränkungen innerhalb einer Tabelle und stellt sicher, dass jede Abfrage ausschließlich die Zeilen sieht, für die sie berechtigt ist.

Einer der größten Vorteile von RLS besteht darin, dass Zugriffsregeln direkt in der Datenbank durchgesetzt werden, anstatt über den Anwendungscode verteilt zu sein. Diese Zentralisierung bedeutet, dass es genau einen Ort gibt – die Policy auf der Datenbanktabelle –, an dem die Sicherheitslogik definiert und gepflegt wird. Dadurch sinkt das Risiko, dass ein Fehler in der Anwendung Daten offenlegt (zum Beispiel ein fehlender Filter in einem API-Endpunkt). Ist RLS auf einer Tabelle korrekt konfiguriert, enthalten alle Abfragen (SELECT, UPDATE, DELETE), die von nicht privilegierten Rollen ausgeführt werden, automatisch den Sicherheitsfilter. Eine fehlerhaft geschriebene Query kann ihn somit nicht umgehen.

Aktivieren und Anwenden von Row-Level-Security-Policies

RLS wird über Policies implementiert, die auf Tabellen definiert sind. Standardmäßig besitzen Tabellen keine RLS-Policy. Hat ein Benutzer SELECT-Rechte, kann er daher alle Zeilen sehen. Sobald RLS aktiviert ist, verlangt PostgreSQL, dass jede Zeile vor der Rückgabe oder Änderung eine Policy-Prüfung besteht. Ist RLS aktiviert, aber keine Policy definiert, gilt standardmäßig „deny all“: Es sind weder Zeilen sichtbar noch bearbeitbar, bis eine Policy hinzugefügt wird.

Das Aktivieren von RLS auf einer Tabelle erfolgt mit folgendem Befehl:

ALTER TABLE my_table ENABLE ROW LEVEL SECURITY;

Nach der Aktivierung erstellen Sie eine oder mehrere Richtlinien mit CREATE POLICY. Eine Richtlinie definiert einen booleschen Ausdruck, der Zeilen für bestimmte Operationen (SELECT, INSERT, UPDATE, DELETE) filtert und kann für bestimmte Rollen oder für PUBLIC (alle Rollen) gelten. Um beispielsweise Selects in einer Dokumententabelle auf Zeilen zu beschränken, deren owner_id mit der ID des aktuellen Benutzers übereinstimmt, könnten Sie schreiben:

CREATE POLICY docs_select_own ON documents
FOR SELECT
USING (owner_id = current_setting('app.user_id'))::int);

Für Schreiboperationen sollten WITH CHECK-Klauseln in INSERT- und UPDATE-Policies verwendet werden, um sicherzustellen, dass Benutzer keine Zeilen anlegen oder verändern können, die für sie später nicht sichtbar wären.

Wichtig: RLS arbeitet zusammen mit dem regulären Berechtigungssystem von PostgreSQL, ersetzt dieses jedoch nicht. Ein Benutzer muss weiterhin die entsprechenden Tabellenrechte besitzen (vergeben über GRANT), um Operationen ausführen zu dürfen. RLS fügt darauf lediglich eine zusätzliche Filterebene hinzu. So kann beispielsweise GRANT SELECT ON documents TO app_user_role einer Rolle grundsätzlich Lesezugriff geben, während die RLS-Policies festlegen, welche Zeilen tatsächlich sichtbar sind. Hat ein Benutzer kein SELECT-Recht, gewährt RLS dieses nicht – die Tabelle kann schlicht nicht abgefragt werden.

Berechtigungsverhalten unter RLS

Superuser und Rollen mit dem Attribut BYPASSRLS überspringen Row-Level-Security-Prüfungen vollständig. Auch der Owner einer Tabelle ist standardmäßig ausgenommen, da Tabellenbesitzer typischerweise administrative Rollen sind. Verbindet sich Ihre Anwendung daher als Tabellen-Owner oder als Superuser, werden RLS-Policies in dieser Session nicht durchgesetzt.

Um sicherzustellen, dass RLS greift, sollte die Anwendung eine dedizierte Rolle verwenden, die nicht Eigentümer der Tabellen ist. Erstellen Sie beispielsweise eine Rolle app_user mit eingeschränkten Rechten und lassen Sie die Anwendung als diese Rolle authentifizieren. Gewähren Sie Zugriff auf die benötigten Tabellen, ohne Ownership zu vergeben. In dieser Konfiguration werden RLS-Policies wie vorgesehen ausgewertet.

Permissive vs. Restriktive Policies

PostgreSQL-Policies sind standardmäßig permissive. Mehrere permissive Policies auf einer Tabelle werden mit einem logischen ODER verknüpft – sobald eine Policy Zugriff erlaubt, ist die Zeile zugänglich. Dadurch eignen sich permissive Policies gut für breite, allgemeine Regeln.

Beispielsweise könnte eine permissive Policy für alle Operationen (*) definiert werden, die es jedem Mitarbeiter erlaubt, Dokumente innerhalb der eigenen Organisation zu lesen und zu aktualisieren:

CREATE POLICY docs_org_policy ON documents
FOR ALL
USING (org_id = current_setting('app.org_id'))::int);

In manchen Fällen sind jedoch strengere Regeln für bestimmte Operationen erforderlich. Hier kommen restrictive Policies zum Einsatz. Restrictive Policies werden mit einem logischen UND kombiniert – alle restriktiven Bedingungen müssen erfüllt sein, zusätzlich zu etwaigen permissiven Policies.

Um beispielsweise sicherzustellen, dass nur der Eigentümer ein eigenes Dokument löschen kann, kann eine restrictive Policy für DELETE definiert werden:

CREATE POLICY docs_delete_own ON documents
AS RESTRICTIVE
FOR DELETE
USING (owner_id = current_setting('app.user_id'))::int);

Diese Kombination ermöglicht eine geschichtete Zugriffskontrolle: Permissive Policies definieren die Basis, während restrictive Policies die Einschränkungen für sensible Operationen weiter verschärfen

Fazit

PostgreSQL kann als praxisnaher Vector Store für RAG-Systeme dienen, indem pgvector für semantisches Retrieval mit Full Text Search für keywordbasierte Suche kombiniert wird. Einfache Fusionsmethoden wie Reciprocal Rank Fusion verbessern die Ergebnisqualität, ohne eine komplexe Kalibrierung von Scores zu erfordern, und beide Sucharten lassen sich parallel ausführen. Row-Level Security verhindert anschließend Datenlecks zwischen Nutzern, indem Zugriffsregeln direkt innerhalb der Datenbank-Engine durchgesetzt werden. Zusammengenommen ermöglichen diese Funktionen den Aufbau einer Retrieval-Pipeline auf vertrauter Infrastruktur – mit fein abstimmbarer Performance, zentralisierter Autorisierung und minimalem operativem Aufwand.

Autor

Arne Grobrügge
Data Scientist bei der scieneers GmbH
arne.grobrügge@scieneers.de

Schlagwortarchiv für: PostgreSQL

Implementierung von RAG mit PostgreSQL