pgvector RAG Skalierung: HNSW vs. IVFFlat, Chunking, Hybrid-Suche und Performance-Richtwerte (Stand 2026)

Für die pgvector RAG Skalierung sind drei Hebel entscheidend: die Indexwahl (HNSW für stabile Abfragezeiten, IVFFlat für schnellen Aufbau), sauberes Chunking mit 300–800 Tokens pro Abschnitt sowie Hybrid-Suche mit Reranking. Damit sind RAG-Pipelines im Millionenbereich an Vektoren realisierbar – mit Abfragezeiten, die in Praxisprojekten typischerweise zwischen 10 und 50 Millisekunden liegen (Stand 2026).

pgvector RAG Skalierung: Warum ab rund 100.000 Vektoren der Index entscheidet

Viele Mittelständler, Kanzleien und Praxen starten ihre RAG-Prototypen mit einer überschaubaren Wissensbasis. Bis etwa 50.000 bis 100.000 Vektoren liefert der sequenzielle Scan in Postgres noch brauchbare Antwortzeiten, danach wächst die Latenz linear mit der Datenmenge. Für produktive Anwendungen braucht es einen Approximate-Nearest-Neighbor-Index – und der wirkt auf mehreren Ebenen: auf Abfragegeschwindigkeit, Speicherbedarf und Trefferqualität. pgvector bringt dafür mit HNSW und IVFFlat zwei ausgereifte Index-Typen mit, die für unterschiedliche Lastprofile konzipiert sind.

Indexwahl für die pgvector RAG Skalierung: HNSW vs. IVFFlat

HNSW: stabile Abfragezeiten bei hohem Recall

HNSW (Hierarchical Navigable Small World) organisiert die Vektoren als mehrschichtiges Graphmodell und liefert auch bei mehreren Millionen Einträgen konstant kurze Antwortzeiten. Entscheidende Parameter sind m (Verbindungen pro Knoten, Standard 16, für hohe Recall-Ansprüche bis 48), ef_construction (64–128 als Kompromiss aus Bauzeit und Qualität) und ef_search (40–100 im Betrieb). Mit ef_search um 80 sind Recall-Werte über 0,95 realistisch. Der Preis: Der Indexaufbau ist rechenintensiv – für eine Million 1536-dimensionaler Vektoren auf einem 8-vCPU-System sollten Sie mit 30 bis 90 Minuten rechnen.

IVFFlat: schneller Aufbau für wachsende Wissensbasen

IVFFlat teilt die Daten in Cluster (lists) und durchsucht pro Anfrage nur die relevantesten davon. Faustregel für die Listenanzahl: Zeilen geteilt durch 1000 bis etwa eine Million Vektoren, danach ungefähr die Wurzel aus der Zeilenanzahl; die Anzahl der durchsuchten Cluster (probes) liegt praktisch bei 10 bis 30 Prozent. Der Aufbau geht 5- bis 10-mal schneller als bei HNSW, dafür schwanken Abfragezeit und Recall stärker. Wichtig: IVFFlat erst nach dem Bulk-Import erstellen, da leere Cluster den Recall drücken – bei stark veränderten Daten hilft nur ein Neuaufbau.

• Statische, leselastige Bestände (Vertragsarchiv, Handbücher, Richtlinien): HNSW bevorzugen.
• Häufig aktualisierte Bestände (Rechtsprechung, News, Tickets): IVFFlat mit nächtlichem Neuaufbau oder HNSW mit Reindex-Strategie.
• 1536-dimensionale Embeddings gängiger Sprachmodelle: ein halfvec-Index halbiert den Speicherbedarf und beschleunigt die Suche typischerweise um den Faktor 1,5 bis 2 bei minimalem Qualitätsverlust.

Chunking als unterschätzter Hebel der pgvector RAG Skalierung

Die Indexwahl wirkt immer nur auf das, was das Chunking zuvor erzeugt hat. Bewährte Richtwerte: 300 bis 800 Tokens pro Chunk, geschnitten an Satz- und Absatzgrenzen, mit einer Überlappung von 10 bis 20 Prozent (bei 500-Token-Chunks also 50 bis 100 Tokens). Kleinere Chunks erhöhen die inhaltliche Treffgenauigkeit, vergrößern aber den Index – aus zehn Millionen Tokens Ausgangstext ergeben sich bei 400er-Chunks rund 25.000 Vektoren, bei 200er-Chunks verdoppelt sich der Bestand.

Zu jedem Chunk gehören Metadaten: Dokument-ID, Überschriftenpfad, Datum, Dokumenttyp sowie Mandanten- beziehungsweise Patientenkontext. Gerade für Kanzleien und Praxen sind Zugriffsrechte Pflicht, damit die Vektorsuche mandantentrennend gefiltert werden kann. Bei HNSW empfiehlt sich dafür der iterative Scan (pgvector ab Version 0.8), der Filter erst nach der Graphsuche anwendet und so Recall-Einbrüche bei starken Filtern vermeidet.

Hybrid-Suche: Semantik und Präzision in einer Abfrage

Reine Vektorsuche erkennt Bedeutung, schwächelt aber bei exakten Bezeichnern wie Gesetzesparagraphen, Aktenzeichen oder ICD-10-Codes. Die Hybrid-Suche kombiniert deshalb die pgvector-Suche mit der klassischen Volltextsuche (tsvector plus GIN-Index) in einer Postgres-Abfrage und fusioniert beide Rankinglisten – bewährt hat sich Reciprocal Rank Fusion (RRF, k=60). Ein nachgelagerter Cross-Encoder rerankt die Top 20 bis 50 Treffer auf die finale Top-10-Liste. Diese Kombination ist auf Fachsprache ausgelegt und verbessert die Ergebnisqualität in Praxisprojekten spürbar.

Performance-Richtwerte für die pgvector RAG Skalierung (Stand 2026)

• Bis 50.000–100.000 Vektoren: sequenzieller Scan meist ausreichend, Latenzen typischerweise unter 100 ms.
• 1–5 Millionen Vektoren (1536-dim, halfvec-HNSW): p95-Latenzen von 10–50 ms auf einem System mit 8 vCPU und 32 GB RAM erreichbar.
• Recall: über 0,95 mit ef_search 64–100; IVFFlat erreicht mit 10–30 Prozent probes ähnliche Werte bei geringerer Stabilität.
• Speicher: eine Million Vektoren à 1536 Dimensionen belegen rund 6–7 GB als vector und etwa 3–3,5 GB als halfvec – zuzüglich Index-Overhead.
• Bauzeiten: IVFFlat indiziert dieselbe Datenmenge 5- bis 10-mal schneller als HNSW.

Fazit: pgvector RAG Skalierung als Architekturentscheidung

Postgres mit pgvector ist für RAG-Szenarien im Mittelstand bis in den niedrigen Millionenbereich an Vektoren konzipiert – entscheidend ist, Indexwahl, Chunking und Hybrid-Suche als Gesamtarchitektur zu planen, statt sie nachträglich zu optimieren. Wer früh auf halfvec, Metadaten und mandantentrennende Filter setzt, vermeidet später teure Migrationen. Für den praktischen Einstieg mit Django haben wir die pgvector-Pattern aus unseren Engineering Notes zusammengefasst. Wenn Sie einschätzen möchten, welche Indexstrategie zu Ihrer Datenlage und Ihren Compliance-Anforderungen passt, vereinbaren Sie ein Strategiegespräch mit codlab.de.

Haeufige Fragen

Ab wann lohnt sich ein Index statt des sequenziellen Scans?

Bis etwa 50.000 bis 100.000 Vektoren ist der sequenzielle Scan in pgvector meist ausreichend. Danach wächst die Latenz linear mit der Datenmenge, sodass ein HNSW- oder IVFFlat-Index wirtschaftlich sinnvoll wird.

HNSW oder IVFFlat – was passt zu häufig aktualisierten Daten?

IVFFlat baut den Index 5- bis 10-mal schneller auf und eignet sich für Bestände mit nächtlichem Neuaufbau. HNSW liefert stabilere Abfragezeiten, sollte bei starken Datenänderungen aber ebenfalls regelmäßig neu aufgebaut werden.

Was bringt der halfvec-Datentyp bei 1536 Dimensionen?

halfvec halbiert den Speicherbedarf der Embeddings und beschleunigt die Suche typischerweise um den Faktor 1,5 bis 2. Der Recall-Verlust ist in den meisten Szenarien gering.

Wie groß sollten Chunks für die Vektorsuche sein?

Bewährt haben sich 300 bis 800 Tokens pro Chunk mit 10 bis 20 Prozent Überlappung, geschnitten an Satz- und Absatzgrenzen. Kontext wie Dokumenttyp oder Zugriffsrechte gehört als Metadaten auf den Chunk.

Warum Hybrid-Suche statt reiner Vektorsuche?

Exakte Bezeichner wie Paragraphen, Aktenzeichen oder ICD-Codes findet die Volltextsuche zuverlässiger, während die Vektorsuche semantische Treffer liefert. Die Fusion beider Rankings per RRF plus Cross-Encoder-Reranking verbessert die Ergebnisqualität erkennbar.

Bis wann trägt eine einzelne Postgres-Instanz die RAG-Suche?

Als Richtwert gelten 5 bis 10 Millionen Vektoren auf einem gut dimensionierten System (Stand 2026). Darüber sollten Sie Partitionierung, Sharding oder eine dedizierte Vektor-Datenbank in die Architekturbewertung einbeziehen.