Vector Databases · RAG

Vektor-Datenbanken

Eine Vektor-DB speichert hunderttausende bis Milliarden von Embedding-Vektoren und findet zu einer Query-Anfrage in Millisekunden die ähnlichsten — typisch mit einem HNSW-Index (Hierarchical Navigable Small World). Welche du wählst, hängt weniger von der reinen Vector-Performance ab als vom Drumherum.

Faustregel: Wenn du bereits Postgres betreibst, fang mit pgvector an. Sonst hängt's davon ab, wie viel Ops du selbst machen willst.

pgvectorSelf / Postgres-Extension

Hybrid:

Ja (mit tsvector kombinierbar)

Filter:

Volles SQL WHERE

Sweet Spot:

Du hast schon Postgres. Mittelgroße Korpora.

Watch out:

HNSW-Index seit pgvector 0.5 — vorher war's langsam.

PineconeManaged (SaaS)

Hybrid:

Ja (Sparse + Dense Vektor parallel)

Filter:

Metadata-Filter eingebaut

Sweet Spot:

Du willst Skalierung ohne Ops. Multi-Tenancy via Namespaces.

Watch out:

Nicht günstig. Kein lokales Dev — alles über die Cloud.

WeaviateSelf / Managed

Hybrid:

Built-in BM25 + Vector (RRF)

Filter:

GraphQL-Filter

Sweet Spot:

Hybrid out-of-the-box ohne Eigenbau. Module-System für Custom-Embeddings.

Watch out:

Eigenes Datenmodell mit „Klassen“ – Einarbeitung nötig.

QdrantSelf / Managed

Hybrid:

Ja (Sparse via SPLADE)

Filter:

JSON-Payload-Filter (umfangreich)

Sweet Spot:

Performance-fokussiert. Filter-First-Workloads (z.B. Multi-Tenant).

Watch out:

Geringer als Pinecone, aber wachsendes Ecosystem.

ChromaSelf / Embedded

Hybrid:

Nur Dense

Filter:

Einfache Metadata-Filter

Sweet Spot:

Lokales Dev, Prototypen, kleine Apps (<1M Vektoren).

Watch out:

Nicht für Production-Scale ausgelegt — eher Notebook-Friend.

Elasticsearch / OpenSearchSelf / Managed

Hybrid:

Ja (das ist ihr Heimspiel)

Filter:

Volles Query-DSL

Sweet Spot:

Du hast schon Elastic für Volltext. Operationen sind eingespielt.

Watch out:

Vektor-Performance kommt nicht ganz an spezialisierte DBs ran.

Warum eigentlich? — Warum brauchen wir spezialisierte DBs?

Klassische DBs sind für O(log n) Suche auf einer Dimension optimiert (B-Tree-Indizes). Vektor-Suche braucht nächste Nachbarn in n-dimensionalem Raum — naive lineare Suche ist O(n·d) und wird bei Millionen Vektoren langsam. ANN-Indizes wie HNSW liefern eine Approximation in O(log n) bei >95 % Recall.

Häufiger Denkfehler — Vektor-DB-Wahl ist nicht die Engpassstelle

Die meisten RAG-Projekte scheitern nicht an der Vektor-DB-Performance, sondern an: schlechtem Chunking, fehlenden Metadaten-Filtern, keinem Re-Ranking, oder uneindeutigen Quellen. Erst die Pipeline-Qualität polieren, dann die DB-Wahl optimieren.

Tiefer rein — HNSW unter der Haube

HNSW baut einen Graphen über die Vektoren mit mehreren Layern (wie Skip-Lists). Suche fängt im obersten, dünnsten Layer an und navigiert Greedy zum Ziel runter. Trade-off-Parameter: M (Anzahl Verbindungen pro Knoten, typisch 16) und efSearch (Such-Breite, typisch 100–400). Höher = besser, langsamer, mehr RAM.

← Metadaten & Filter Hybrid: BM25 + Vektor →