Serie · 3 Teile · pgturbohybrid
Dense, Hybrid, Late Interaction
Retrieval in PostgreSQL, Schritt für Schritt
Dense-Vektoren finden Bedeutung, BM25 findet das exakte Wort. Ein ernsthaftes Such- oder RAG-System braucht fast immer beides, am liebsten ohne einen zweiten Dienst neben der Datenbank. Diese Serie baut Retrieval Schritt für Schritt direkt in PostgreSQL: erst kompakte Dense-Suche mit pgturbohybrid, dann lexikalische Evidenz über BM25, schließlich Late Interaction mit vielen Vektoren pro Dokument.
01
ein Vektor pro Dokument
02
Vektor + exakte Begriffe
03
viele Token-Vektoren
01
TurboQuant in PostgreSQL
Efficient Dense Retrieval with 4-bit Graph Codes
Dense-Retrieval mit 4-bit-Codes statt voller Float-Vektoren im heißen Indexpfad. SIMD-freundliches Scoring hält die Latenz niedrig, exaktes Reranking kommt nur dann dazu, wenn es zählt.
4-bit codesSIMDReranking
02
Hybrid Retrieval in PostgreSQL
Integrating BM25 and Dense Vectors with RRF
Semantische Kandidaten aus dem TurboQuant-Graph, exakte Treffer aus dem BM25-Zweig, zusammengeführt per Reciprocal-Rank-Fusion. Die Fusion passiert im Indexzugriff selbst, nicht in einer SQL-Konstruktion drumherum.
BM25RRFHybrid-Index
03
Late Interaction in PostgreSQL
Multivector Retrieval with pgturbohybrid and ColBERT Integration
Nicht ein Vektor pro Dokument, sondern viele Token-Vektoren. Jedes Query-Token sucht seinen besten Match, MaxSim summiert die Treffer. ColBERT-Stil, lokal eingebettet über pg_colbert_llama.
MaxSimMultivectorColBERT
Worum es geht
Embeddings, Volltext & Fusion in PostgreSQL
Suche steckt heute in fast jedem Produkt: in der Doku, im Support-Tool, im RAG-System hinter einem Chatbot. Der klassische Weg dahin führt über eine eigene Vektordatenbank, die neben der eigentlichen Datenbank läuft, in der die Inhalte ohnehin schon liegen. Zwei Systeme nebeneinander, beide wollen betrieben und synchron gehalten werden.
Der Gedanke hinter pgturbohybrid ist unspektakulär, und genau deshalb interessant. Wenn die Daten sowieso in PostgreSQL liegen, kann die Suche gleich mitwohnen: Embeddings, Volltext und Fusion im selben System, abgefragt über dasselbe SQL, gesichert über dasselbe Backup.
Für viele Projekte verschwindet damit eine ganze Betriebsebene. Kein zweiter Dienst, der nachts umkippt. Und wer später wirklich an Grenzen stößt, kann immer noch auf eine dedizierte Engine wechseln, statt sie schon ab Tag eins zu brauchen.
Die drei Teile oben zeigen, wie weit das trägt, von der kompakten Dense-Suche bis zu Late Interaction mit vielen Vektoren pro Dokument.
Der Bogen
Retrieval-Stack in PostgreSQL
Die Reihenfolge ist kein Zufall, jeder Artikel reicht den nächsten an. Teil 1 hört dort auf, wo Dense-Suche an ihre Grenze stößt: bei exakten Strings, IDs und seltenen Begriffen, die ein Embedding verwischt. Teil 2 holt dafür BM25 dazu und fusioniert beide Signale per RRF. Weil ein einzelner Vektor pro Dokument aber immer eine Zusammenfassung bleibt, öffnet Teil 3 die Tür zu vielen Token-Vektoren und MaxSim.
Am Ende steht weniger „eine Vektorspalte mit Index“ als ein kompletter Retrieval-Stack in PostgreSQL: Embedding-Erzeugung, Token-Level-Suche, lexikalische Evidenz, Rank-Fusion, Diagnostik, am Schluss ganz normale SQL-Zeilen.
Das Ganze gibt’s übrigens auch als PostgreSQL-Extension:
Benchmark
Ein Referenzpunkt, kein Naturgesetz
Der DBPedia-Benchmark aus dem README unseres Plugins läuft auf einer Million Vektoren, ursprünglich aufgesetzt von den Leuten bei qdrant. Retrieval-Performance hängt von Embedding-Modell, Dimensionen, Korpus und Hardware ab, die Zahlen gelten also nur für genau diesen Aufbau. Interessant ist weniger der Sieger als die Form des Tradeoffs.
| Engine / Profil | recall@10 | Queries/s | Latenz ø |
|---|---|---|---|
| pgturbohybrid · dense | 0,836 | 5739 | 1,27 ms |
| pgturbohybrid · high_recall | 0,983 | 2800 | 2,71 ms |
| pgvector HNSW | 0,979 | 1770 | 4, 37 ms |
| qdrant | 0,986 | 853 | 9,24 ms |
| milvus | 0,988 | 750 | 10.39 ms |
| weaviate | 0,977 | 2633 | 2,90 ms |
Quelle: DBPedia Dense Benchmark, pgturbohybrid README. Als Orientierung gedacht, nicht als universelle Aussage.
Einordnung
Lohnt sich der Weg für dich?
Der Ansatz passt nicht überall. Gut passt er, wenn:
- dein Stack ohnehin PostgreSQL-first ist und du nicht ab Tag eins einen zweiten Vektordienst betreiben willst;
- kompakter Index-Speicher und niedrige Latenz zählen, approximatives Retrieval für deinen Fall aber okay ist;
- du Recall und Profile auf deinen eigenen Daten messen kannst, statt dich auf fremde Benchmarks zu verlassen.
Brauchst du dagegen verteilte, voll gemanagte Vektorsuche mit harter Betriebsisolierung, bleibt eine dedizierte Engine womöglich die bessere Wahl. Der Punkt der Serie ist ein anderer: PostgreSQL deckt mehr vom Retrieval-Stack ab, als viele Teams annehmen.
… ODER
Direkt Kontakt aufnehmen
Für den Fall, dass du dich direkt mit uns austauschen möchtest – fülle das Formular aus; wir melden uns bei dir!
Dieses Formular wird über HubSpot eingebunden und benötigt Marketing-Cookies, die du gerade nicht akzeptiert hast.
Lieber direkt: kontakt@mayflower.de