Lösungen für
Bitte auswählen
Web-App testen
ki-werkzeuge

Vektor-Datenbanken

Redaktion ·

Wozu eine eigene Datenbank für Zahlenkolonnen — und warum dich das angeht

Sobald du irgendetwas mit semantischer Suche, RAG oder Empfehlungen baust, stößt du auf eine Klasse von Datenbanken, die nicht nach Strings, IDs oder Datumsfeldern sucht, sondern nach Ähnlichkeit. Eine Vektor-Datenbank speichert nicht „das Wort Apfel”, sondern eine Liste aus mehreren hundert bis tausend Fließkommazahlen, die die Bedeutung von „Apfel” in einem Modellraum abbilden. Und sie kann zu einer beliebigen Anfrage in Millisekunden die ähnlichsten gespeicherten Vektoren finden — auch in einer Sammlung von Millionen Einträgen.

Das ist der Unterschied zur klassischen Volltextsuche: Eine relationale Datenbank findet Dokumente, die das Wort „Kündigungsfrist” enthalten. Eine Vektor-Datenbank findet Dokumente, die inhaltlich um Kündigungsfristen gehen — auch wenn dort „Vertrag beenden” oder „aussteigen” steht. Diese semantische Nähe ist die Grundlage fast aller modernen KI-Retrieval-Systeme.

Dieser Artikel erklärt die Grundmechanik (Embeddings, Distanzmaße, ANN-Indizes), zeigt die fünf wichtigsten Optionen — Chroma, Weaviate, Milvus, Qdrant und pgvector — im direkten Vergleich, und gibt eine Entscheidungshilfe entlang der Achsen, an denen die Wahl wirklich hängt. Stand: Juni 2026. Die Featuresets bewegen sich schnell, die Auswahlkriterien bleiben stabil.

Grundmechanik: Was passiert beim Speichern und Suchen

Vom Text zum Vektor — das Embedding

Am Anfang steht das Embedding: Ein Modell wandelt einen Text (oder ein Bild, ein Audio-Snippet) in einen festen Vektor um — etwa 384, 768, 1024 oder 3072 Dimensionen, je nach Modell. Inhaltlich ähnliche Eingaben landen in diesem Raum nah beieinander, unähnliche weit auseinander. Die Vektor-Datenbank speichert diese Vektoren zusammen mit einer ID und optionalen Metadaten (Quelle, Datum, Kategorie, Zugriffsrechte).

Wichtig: Die Datenbank erzeugt die Embeddings in der Regel nicht selbst. Du rufst ein Embedding-Modell (OpenAI, Cohere oder ein Self-Hosted-Modell) auf und schreibst das Ergebnis hinein. Manche Datenbanken bieten integrierte Embedding-Module an, die diesen Schritt kapseln — das ist Komfort, kein Pflichtfeature.

Distanzmaße — wie „Ähnlichkeit” gemessen wird

Ähnlichkeit zwischen zwei Vektoren wird über ein Distanzmaß berechnet. Drei sind verbreitet:

  • Cosine (Kosinus-Ähnlichkeit): misst den Winkel zwischen Vektoren, ignoriert die Länge. Standard für Text-Embeddings.
  • Dot Product (Skalarprodukt): schnell, berücksichtigt auch die Magnitude. Wird oft bei normalisierten Vektoren genutzt, dann äquivalent zu Cosine.
  • Euclidean (L2): geometrischer Abstand. Verbreitet bei Bild-Embeddings.

Welches Maß richtig ist, gibt das Embedding-Modell vor — nicht die Datenbank. Das falsche Maß zu wählen ist ein häufiger und stiller Fehler: Die Suche liefert Ergebnisse, nur eben schlechtere, ohne dass etwas crasht.

ANN statt exakter Suche — der eigentliche Trick

Bei einer Million Vektoren mit jeweils 1024 Dimensionen wäre der exakte Vergleich jeder Anfrage mit jedem Eintrag (Brute Force) zu langsam. Deshalb nutzen Vektor-Datenbanken ANN (Approximate Nearest Neighbor): Indexstrukturen, die fast immer die richtigen Treffer finden, aber drastisch schneller. Der bekannteste Index ist HNSW (Hierarchical Navigable Small World) — ein mehrschichtiger Graph, durch den die Suche von grob nach fein navigiert. Daneben gibt es IVF (Inverted File, Clustering) und disk-basierte Verfahren wie DiskANN, die nicht den ganzen Index im RAM halten müssen.

Der Trade-off heißt Recall vs. Speed: Recall ist der Anteil der tatsächlich nächsten Nachbarn, die der Index zurückgibt. 99 % Recall heißt, dass 1 % der besten Treffer verfehlt wird — für die meisten RAG-Anwendungen unsichtbar, dafür um Größenordnungen schneller als exakte Suche. Diese Stellschraube (bei HNSW über Parameter wie ef_search) ist das Herzstück der Performance-Abstimmung.

Die Achsen, an denen die Wahl wirklich hängt

Bevor wir einzelne Systeme vergleichen, lohnt ein klares Achsenkreuz. Marketingseiten vermischen das gerne.

Self-Hosted vs. Managed

Betreibst du die Datenbank selbst (Docker, Kubernetes, Bare Metal) oder kaufst du sie als Cloud-Dienst? Self-Hosted gibt volle Kontrolle und Datenhoheit, kostet aber Betriebsaufwand — Backups, Skalierung, Updates. Managed nimmt dir das ab, bindet dich aber an einen Anbieter und verlagert sensible Daten in dessen Cloud. Fast alle hier genannten Systeme gibt es in beiden Varianten.

Eingebettet vs. Server

Manche Systeme laufen als Bibliothek direkt im Prozess deiner Anwendung (eingebettet, wie SQLite). Andere sind eigenständige Server, mit denen mehrere Clients über Netzwerk reden. Eingebettet ist ideal für Prototypen und kleine Datensätze, Server für Produktion und parallele Zugriffe.

Filtering — Metadaten plus Vektor

In der Praxis suchst du selten rein semantisch. Du willst „die ähnlichsten Dokumente, aber nur aus 2026, nur Kategorie Recht, nur die der User sehen darf”. Dieses gefilterte ANN ist technisch knifflig, weil Filter und Index-Navigation sich gegenseitig stören können. Wie gut ein System pre-filtering (Filter zuerst) und post-filtering (Filter nach der Suche) beherrscht, ist ein hartes Unterscheidungsmerkmal.

Hybrid-Suche

Reine Vektorsuche ist schlecht bei exakten Begriffen, Produktnummern, seltenen Eigennamen. Hybrid-Suche kombiniert Vektor-Ähnlichkeit mit klassischer Keyword-Suche (BM25) und führt die Ergebnisse zusammen. Für viele Produktivanwendungen ist das der größere Qualitätshebel als das letzte Prozent Recall.

Skalierung

Bis ein paar Millionen Vektoren ist fast alles schnell genug. Die Unterschiede zeigen sich bei zweistelligen Millionen und darüber — dann trennt sich, was auf einem Knoten läuft, von dem, was horizontal über Cluster skaliert.

Die fünf Optionen im Profil

pgvector — Vektorsuche in Postgres

pgvector ist eine Erweiterung für PostgreSQL, kein eigenständiges System. Der Reiz: Wenn deine App ohnehin Postgres nutzt, bekommst du Vektorsuche ohne zweite Datenbank, ohne Sync-Problem, mit transaktionaler Konsistenz und vollem SQL inklusive JOIN und WHERE. Filtering über Metadaten ist damit trivial — es ist einfach eine SQL-Bedingung.

Die Grenze liegt bei der Skalierung. Standard-HNSW in pgvector wird laut Benchmarks oberhalb von etwa 5–10 Millionen Vektoren spürbar langsamer, und der Index sollte für gute Performance in den RAM passen — bei 50 Millionen Vektoren mit 768 Dimensionen sind das grob 150 GB+ Arbeitsspeicher. Die Erweiterung pgvectorscale (von Timescale) verschiebt diese Decke deutlich nach oben: Sie bringt StreamingDiskANN, einen disk-basierten Index, und erreicht laut Timescale-Benchmark (Mai 2025) rund 471 QPS bei 99 % Recall auf 50 Millionen Vektoren — was die Lücke zu dedizierten Systemen schließt. Diese Zahlen stammen vom Anbieter; im eigenen Workload nachmessen.

Qdrant — schnell und Rust-basiert

Qdrant ist eine dedizierte Vektor-Datenbank, in Rust geschrieben, mit Fokus auf Geschwindigkeit und ausgereiftem Filtering. In gängigen Benchmarks 2026 liegt Qdrant bei den Open-Source-Optionen vorn: Bei 10 Millionen Vektoren wird eine P99-Latenz um 12 ms berichtet, gegenüber 16 ms (Weaviate) und 18 ms (Milvus) — etwa 10–25 % schneller bei vergleichbaren Workloads. Die Rust-Basis schlägt sich in diesen Latenzen nieder. Gibt es Self-Hosted und als Qdrant Cloud. Gute Wahl, wenn Vektorsuche im Zentrum einer neuen App steht und Tempo zählt.

Weaviate — stark bei Hybrid-Suche

Weaviate ist eine dedizierte Vektor-Datenbank mit besonderem Fokus auf Hybrid-Suche und integrierte Embedding-Module (Text, Bild, multimodal). Wenn du Vektor- und Keyword-Suche von Haus aus kombiniert haben willst, ohne das selbst zu verdrahten, spielt Weaviate seine Stärke aus. Latenz liegt knapp hinter Qdrant, dafür ist das Featureset um Hybrid und Modularität reicher. Self-Hosted und als Managed Cloud verfügbar.

Milvus — für Milliarden-Skalierung

Milvus ist die schwergewichtige Option für sehr große Datenmengen. Die Architektur ist auf horizontale Skalierung ausgelegt (verteilte Knoten, Trennung von Storage und Compute) und zielt auf Milliarden von Vektoren. Der Preis dafür ist Betriebskomplexität: Milvus voll auszufahren setzt ein Ops-Team voraus. Für kleine bis mittlere Projekte ist es Overkill; für echte Big-Scale-Suche mit eigenem Betriebsteam die richtige Wahl. Der gehostete Dienst Zilliz Cloud nimmt einen Teil der Komplexität ab.

Chroma — der Prototyping-Liebling

Chroma ist auf Entwicklerfreundlichkeit getrimmt: In wenigen Zeilen Python eingebettet startklar, ideal für lokale Experimente und kleine RAG-Prototypen. Die Produktionsreife ist 2025 und 2026 deutlich gewachsen (Server-Modus, gehostete Variante), für ernsthaft große Workloads liegt Chroma aber weiter hinter Qdrant und Weaviate. Die Stärke ist der schnelle Einstieg, nicht die letzte Skalierungsstufe.

Vergleichstabelle

| System | Typ | Stärke | Skalierung | Hybrid-Suche | Betrieb | |---|---|---|---|---|---| | pgvector | Postgres-Erweiterung | Keine zweite DB, volles SQL | bis ~10M (mit pgvectorscale deutlich mehr) | über SQL/Extensions | gering, wenn Postgres schon da | | Qdrant | dediziert (Rust) | Geschwindigkeit, Filtering | sehr gut (verteilt) | ja | mittel | | Weaviate | dediziert | Hybrid-Suche, Module | sehr gut | stark integriert | mittel | | Milvus | dediziert (verteilt) | Milliarden-Skala | extrem | ja | hoch (Ops-Team) | | Chroma | eingebettet/Server | schneller Einstieg | klein bis mittel | begrenzt | sehr gering |

Die Latenz- und QPS-Zahlen im Text stammen aus öffentlichen Benchmarks 2025/2026 (siehe Quellen) und hängen stark von Hardware, Dimensionalität und Recall-Ziel ab. Behandle sie als Größenordnung, nicht als Garantie — im eigenen Workload nachmessen.

Entscheidungshilfe für vier Situationen

Du hast bereits Postgres und unter ~50M Vektoren: pgvector. Keine zweite Datenbank, transaktionale Konsistenz, Filtering per SQL. Bei wachsender Last pgvectorscale dazunehmen.

Vektorsuche ist Kern einer neuen App, mittlere Skala, Tempo zählt: Qdrant. Wenn stattdessen Hybrid-Suche der Hebel ist: Weaviate.

Du prototypst in Python und willst schnell etwas Funktionierendes: Chroma. Später bei Bedarf migrieren.

Milliarden von Vektoren und ein echtes Ops-Team: Milvus (oder Vespa als Alternative).

Stolperfallen

  • Falsches Distanzmaß: Nicht zum Embedding-Modell passendes Maß liefert leise schlechtere Treffer. Im Modell-Steckbrief nachschauen.
  • Index zu klein dimensioniert: HNSW-Parameter (m, ef_construction, ef_search) bestimmen Recall und Geschwindigkeit. Defaults sind selten optimal für den eigenen Datensatz.
  • Filtering unterschätzt: Erst spät merken, dass man pre-filtering braucht, kann eine Migration erzwingen. Die Filter-Anforderungen vorab klären.
  • Embeddings nicht versioniert: Wechselst du das Embedding-Modell, sind alte und neue Vektoren inkompatibel. Du musst den gesamten Bestand neu einbetten.
  • RAM-Bedarf unterschätzt: Wenn der HNSW-Index nicht in den Speicher passt, bricht die Performance ein. Vor dem Skalieren rechnen.

FAQ

Brauche ich überhaupt eine eigene Vektor-Datenbank?
Nicht zwingend. Für ein paar tausend Vektoren reicht oft eine In-Memory-Suche oder pgvector in der bestehenden Postgres-Instanz. Eine dedizierte Vektor-Datenbank lohnt sich, sobald Datenmenge, Filtering-Bedarf oder Latenz-Anforderungen die einfache Lösung sprengen.
Was ist der Unterschied zwischen Vektor-Datenbank und RAG?
RAG (Retrieval-Augmented Generation) ist das Gesamtkonzept: relevante Dokumente abrufen und einem Sprachmodell als Kontext mitgeben. Die Vektor-Datenbank ist eine Komponente darin — der Speicher, aus dem das Retrieval die ähnlichsten Chunks holt. RAG braucht zusätzlich Chunking, Embedding und oft Reranking.
Was bedeutet HNSW?
Hierarchical Navigable Small World — ein graphbasierter ANN-Index. Die Suche navigiert durch mehrere Ebenen eines Graphen von groben zu feinen Nachbarschaften und findet so sehr schnell annähernd die nächsten Nachbarn. Der heute am weitesten verbreitete Index für Vektorsuche.
Cosine oder Dot Product — was nehme ich?
Das gibt das Embedding-Modell vor. Für normalisierte Vektoren sind beide äquivalent; viele Text-Modelle empfehlen Cosine. Im Zweifel die Empfehlung des Modellanbieters befolgen statt selbst zu raten.
Kann pgvector mit dedizierten Datenbanken mithalten?
Bis in den niedrigen zweistelligen Millionenbereich ja, besonders mit pgvectorscale und disk-basiertem DiskANN-Index. Bei Hunderten Millionen bis Milliarden Vektoren mit hohen Durchsatzanforderungen sind dedizierte, verteilte Systeme wie Milvus weiterhin im Vorteil.

Fazit

Vektor-Datenbanken sind das Rückgrat semantischer Suche und von RAG. Die Mechanik ist überall gleich — Embeddings rein, ANN-Index, Ähnlichkeitssuche mit Recall-Speed-Trade-off. Der Unterschied liegt in Betrieb, Filtering, Hybrid-Suche und Skalierung. Für die meisten Teams ist die ehrlichste Antwort: mit pgvector starten, wenn Postgres da ist; zu Qdrant oder Weaviate wechseln, wenn Vektorsuche zum Kern wird; Milvus erst, wenn die Skala es wirklich erzwingt. Wähle nach deinen realen Anforderungen, nicht nach dem Benchmark mit der größten Zahl.

Themenuebersicht

KI-WerkzeugeVektor-Datenbanken