Vektordatenbanken verständlich erklärt: Indizes und Vektorsuche

Eine Vektordatenbank (Vector Database) ist ein Datenbanksystem, das speziell für das effiziente Speichern, Verwalten und Durchsuchen von hochdimensionalen Vektoren (Embeddings) entwickelt wurde. Im Gegensatz zu traditionellen relationalen Datenbanken, die Daten in Tabellen speichern und nach exakten Werten oder Textmustern durchsuchen, suchen Vektordatenbanken nach mathematischer Ähnlichkeit im n-dimensionalen Raum.

Vektordatenbanken sind das technische Rückgrat moderner RAG-Architekturen: Sie speichern die eingebetteten Dokument-Chunks und liefern bei jeder Anfrage in Millisekunden die semantisch passendsten Treffer. Ohne sie wäre die Vektorsuche über grosse Wissensbestände nicht in Echtzeit möglich.

Relationale vs. Vektordatenbanken: Der Paradigmenwechsel

Traditionelle Datenbanken sind darauf optimiert, strukturierte Daten exakt abzufragen.

• SQL-Abfrage: SELECT * FROM produkte WHERE name = 'Notebook' -> Findet exakt den Datensatz mit dem String „Notebook“.
• Vektor-Abfrage: Finde die 5 Einträge, deren Vektordarstellung dem Vektor von „mobiler Computer“ am ähnlichsten sind. -> Findet Einträge wie Laptop, Notebook oder MacBook, selbst wenn das Wort „mobil“ oder „Computer“ dort gar nicht vorkommt.

In einer Vektordatenbank sind die Daten keine starren Zeilen, sondern Punkte in einem Koordinatensystem. Die Abfrage besteht darin, den Abstand von einem Abfragepunkt zu allen gespeicherten Punkten zu messen.

---

Die Näherungssuche (Approximate Nearest Neighbor - ANN)

Da der exakte Vergleich eines Vektors mit Millionen anderen Einträgen (ein sogenannter Linear Scan) zu langsam für Echtzeitanwendungen wäre, nutzen Vektordatenbanken Algorithmen zur Näherungssuche (ANN). Diese Algorithmen opfern eine minimale Genauigkeit, um die Suchgeschwindigkeit um Faktoren von Tausenden zu erhöhen.

Die zwei bekanntesten Index-Strukturen sind:

1. Inverted File Index (IVF)

IVF unterteilt den Vektorraum mithilfe von Clustering-Verfahren (z. B. k-Means) in verschiedene Regionen (Voronoi-Zellen). Bei einer Suchabfrage wird zunächst ermittelt, in welcher Region der Suchvektor liegt. Die Suche beschränkt sich anschliessend ausschliesslich auf die Vektoren innerhalb dieser Zelle und ihrer direkten Nachbarn. Dies spart Rechenzeit, da der Grossteil der Datenbank ignoriert werden kann.

2. Hierarchical Navigable Small World (HNSW)

HNSW baut einen mehrschichtigen Graphen über die Vektoren auf.

• Die oberen Schichten enthalten nur wenige, weit voneinander entfernte Knoten (Schnellstrassen).
• Die unteren Schichten werden immer dichter, bis auf der untersten Ebene alle Vektoren miteinander verknüpft sind (Wohnstrassen).
• Der Suchvorgang: Die Engine startet oben, macht grosse Sprünge in Richtung des Suchziels und wechselt dann auf tiefere Ebenen, um die Feinabstimmung vorzunehmen. HNSW ist extrem schnell und präzise, benötigt jedoch relativ viel Arbeitsspeicher (RAM).

---

Bekannte Vertreter am Markt

Es gibt zwei Ansätze, um Vektordatenbanken in der Praxis zu nutzen:

1. Spezialisierte Vektordatenbanken (Native Vector DBs): Systeme wie Qdrant, Pinecone, Milvus oder Chroma sind von Grund auf nur für diesen Zweck optimiert. Sie skalieren hervorragend bei sehr grossen Vektormengen.
2. Vektorfähige klassische Datenbanken: Erweiterungen wie pgvector für PostgreSQL oder Vektormodule für Redis und Elasticsearch. Dies hat den Vorteil, dass Unternehmen ihre bestehende, bewährte Infrastruktur weiternutzen und relationale Daten direkt mit Vektoren verknüpfen können.

---

IVF vs. HNSW: Welcher Index für welchen Fall?

Die Wahl des Index-Verfahrens ist ein Abwägen zwischen Geschwindigkeit, Genauigkeit und Speicherbedarf. Die folgende Übersicht fasst die beiden gängigsten Verfahren zusammen:

Kriterium	IVF (Inverted File)	HNSW (Graph)
Suchgeschwindigkeit	Hoch	Sehr hoch
Genauigkeit (Recall)	Mittel bis hoch (tunebar via nprobe)	Sehr hoch
Speicherbedarf (RAM)	Gering	Hoch
Aufbauzeit des Index	Schnell	Langsamer
Eignung	Sehr grosse Datenmengen, RAM-knapp	Beste Latenz/Qualität, RAM verfügbar

Faustregel: HNSW ist heute der Standard für die meisten Anwendungen mit hohem Qualitätsanspruch. IVF spielt seine Stärke aus, wenn der Arbeitsspeicher knapp ist und sehr grosse Datenmengen verwaltet werden müssen.

---

Spezialdatenbank vs. pgvector im Vergleich

In der Praxis entscheidet sich die Architektur oft zwischen einer dedizierten Vektordatenbank und einer vektorfähigen klassischen Datenbank:

Aspekt	Native Vector DB (Qdrant, Milvus)	pgvector (PostgreSQL)
Skalierung	Exzellent, verteilt	Gut, bis viele Millionen Vektoren
Betriebsaufwand	Zusätzliches System	Bestehende DB weiternutzen
Relationale Joins	Eingeschränkt	Direkt mit SQL-Daten kombinierbar
Tuning-Optionen	Sehr umfangreich	Solide (HNSW, IVFFlat)
Einstieg	Mehr Setup	Minimal, falls PostgreSQL vorhanden

Für viele Unternehmen ist pgvector der pragmatische Startpunkt, weil sich Vektoren und relationale Metadaten in einer einzigen, vertrauten Datenbank halten lassen. Wie das konkret aussieht, zeigt der Artikel zu RAG mit PostgreSQL & pgvector.

---

Praxisbeispiel: Filterung mit Metadaten

Eine reine Ähnlichkeitssuche reicht im Unternehmenskontext selten aus. Meist muss zusätzlich nach Metadaten gefiltert werden – etwa nach Mandant, Sprache oder Berechtigung. Eine typische Abfrage in pgvector kombiniert beides:

SELECT chunk_text
FROM dokumente
WHERE mandant_id = 42          -- Mandantentrennung (relationaler Filter)
ORDER BY embedding <=> :query_vector  -- Kosinus-Distanz (Vektorsuche)
LIMIT 5;

Dieser Pre-Filter (WHERE) stellt sicher, dass ein Nutzer ausschliesslich Dokumente seines eigenen Mandanten erhält – ein wichtiger Baustein für RAG-Sicherheit und Datenschutz in Mehrmandanten-Systemen.

[!TIP] Das Spring-Boot-Backend unserer Schwester-Plattform allerate.dev nutzt PostgreSQL mit der Erweiterung pgvector für eine performante Vektorsuche. Erleben Sie die Funktionsweise in der RAG-Demo live vor Ort.