Vektordatenbanken im Vergleich 2026: Qdrant, Chroma, pgvector, Weaviate, Pinecone & Co.

Artikel-Übersicht

In diesem Leitfaden klären wir zuerst die grundlegende Frage: Wozu brauchst du überhaupt eine Vektordatenbank? Du lernst, was Embeddings sind, warum klassische Datenbanken bei der Ähnlichkeitssuche an ihre Grenzen stoßen und was sich hinter dem Zauberwort ANN-Suche verbirgt. Danach schauen wir unter die Haube: Wir besprechen die wichtigsten Indextypen wie HNSW und IVF, die gängigen Distanzmaße, die Metadaten-Filterung und die immer wichtiger werdende Hybrid-Suche aus Vektor- und Keyword-Treffern. Anschließend gehe ich mit dir die zentralen Auswahlkriterien durch – von Self-hosted vs. Managed über Performance und Filterung bis zu Kosten und Reife. Im Hauptteil vergleichen wir die führenden Lösungen 2026 ausführlich: Qdrant, Chroma, pgvector, Weaviate, Pinecone, Milvus sowie kurz Redis und Elasticsearch. Du bekommst eine kompakte Vergleichstabelle, konkrete Empfehlungen je nach Anwendungsfall und ein lauffähiges Code-Beispiel. Zum Schluss fasse ich alles in praktischen Tipps zusammen und gebe dir echte Links für den Einstieg.

Einleitung: Warum 2026 alle über Vektordatenbanken reden

Wenn du in den letzten zwei Jahren irgendetwas mit KI gebaut hast – einen Chatbot, eine semantische Suche, ein RAG-System –, dann bist du fast zwangsläufig über den Begriff „Vektordatenbank" gestolpert. Und falls du dich gefragt hast, ob das nur ein weiteres Buzzword ist: Nein, ist es nicht. Vektordatenbanken sind das Rückgrat fast jeder modernen KI-Anwendung, die mit eigenen Daten arbeitet.

Die Analogie, die ich am liebsten benutze: Eine klassische Datenbank ist wie ein Bibliothekar, der dir ein Buch nur dann findet, wenn du den exakten Titel kennst. Eine Vektordatenbank dagegen ist wie ein belesener Freund, dem du sagst „ich suche etwas Ähnliches wie diese Geschichte über einen einsamen Roboter" – und der dir sofort drei passende Romane empfiehlt, obwohl in deiner Beschreibung kein einziges Wort aus den Büchern vorkam. Genau diese Fähigkeit, Bedeutung statt nur Buchstaben zu durchsuchen, macht Vektordatenbanken so mächtig.

Das Spannende: Der Markt 2026 ist erwachsen geworden. Wo vor zwei Jahren noch wilde Experimente standen, gibt es heute ausgereifte, produktionsreife Lösungen – von schlanken Embedded-Datenbanken für den Prototypen bis zu Systemen, die Milliarden von Vektoren bändigen. Lass uns gemeinsam Ordnung in das Feld bringen.

Wozu eine Vektordatenbank? Embeddings und Ähnlichkeitssuche

Alles beginnt mit Embeddings. Ein Embedding ist eine Liste von Zahlen – ein Vektor –, die die Bedeutung eines Stücks Text, eines Bildes oder eines Audioclips repräsentiert. Ein Embedding-Modell (etwa von OpenAI, Cohere, Voyage oder ein Open-Source-Modell) verwandelt den Satz „Der Hund spielt im Garten" in beispielsweise 1.536 Fließkommazahlen. Texte mit ähnlicher Bedeutung landen dabei nah beieinander in diesem hochdimensionalen Raum – „Der Welpe tollt auf der Wiese" liegt ganz in der Nähe, „Die Aktienkurse fielen" weit entfernt.

Wenn du das mehr im Detail verstehen willst, lies gern meinen Artikel zu Embeddings verständlich erklärt. Für unseren Zweck reicht: Embeddings sind Koordinaten der Bedeutung.

Jetzt das Problem. Stell dir vor, du hast eine Million solcher Vektoren gespeichert und willst zu einer Nutzerfrage die zehn ähnlichsten Dokumente finden. Naiv müsstest du die Frage in einen Vektor umwandeln und ihn mit allen einer Million Vektoren vergleichen. Das ist eine exakte k-nächste-Nachbarn-Suche (kNN) – mathematisch sauber, aber bei großen Datenmengen quälend langsam. Bei Milliarden Vektoren ist das schlicht unbenutzbar.

Hier kommt die Approximate Nearest Neighbor Search (ANN) ins Spiel: Statt mit allen Vektoren zu vergleichen, nimmt man eine winzige, kontrollierte Ungenauigkeit in Kauf und durchsucht nur clever vorsortierte Kandidaten. Das Ergebnis ist oft 100- bis 1000-mal schneller, bei einer Trefferqualität („Recall") von 95–99 %. Genau diese ANN-Suche ist die Kernkompetenz, für die es Vektordatenbanken überhaupt gibt. Sie speichern Embeddings, indexieren sie für schnelle ANN-Suche und liefern dir in Millisekunden die relevantesten Treffer.

Wie Vektordatenbanken funktionieren: Indizes und Distanzmaße

Das Herzstück jeder Vektordatenbank ist der Index – die Datenstruktur, die ANN überhaupt schnell macht. Zwei Familien dominieren 2026:

HNSW (Hierarchical Navigable Small World) ist der De-facto-Standard. Stell es dir wie ein mehrstöckiges Autobahnnetz vor: Auf der obersten Ebene gibt es nur wenige Knoten mit weiten Sprüngen über das ganze Land, weiter unten wird das Netz immer feinmaschiger. Eine Suche beginnt oben, springt grob in die richtige Region und verfeinert dann Stockwerk für Stockwerk. HNSW liefert exzellente Query-Performance, funktioniert gut mit Updates und ist deshalb in fast jeder modernen Vektordatenbank die erste Wahl. Der Preis: hoher Speicherverbrauch und langsamerer Index-Aufbau.

IVF (Inverted File Index) teilt den Vektorraum stattdessen in viele Cluster (wie Postleitzahl-Gebiete) und durchsucht zur Query-Zeit nur die nächstgelegenen Cluster. IVF ist sparsamer im Speicher und schneller im Aufbau, dafür bei der Suche meist etwas langsamer als HNSW. Daneben gibt es 2026 zunehmend DiskANN-Varianten (für riesige Datenmengen, die nicht in den RAM passen) und GPU-beschleunigte Indizes wie NVIDIAs CAGRA (in Milvus).

Wichtig ist außerdem das Distanzmaß, also wie „Ähnlichkeit" berechnet wird:

Kosinus-Ähnlichkeit – misst den Winkel zwischen Vektoren, ideal für Text-Embeddings (die gängigste Wahl)
Inneres Produkt (Dot Product) – schnell, oft bei bereits normalisierten Vektoren genutzt
Euklidische Distanz (L2) – der „Luftlinien"-Abstand, häufig bei Bild- und räumlichen Daten

Ein weiterer Hebel ist die Quantisierung: Durch Komprimierung der Vektoren (z. B. Scalar- oder Binary-Quantization) lässt sich der Speicherbedarf drastisch senken – Qdrant wirbt etwa mit bis zu 64-facher Reduktion bei nahezu gleichbleibender Qualität. Das spart bares Geld, sobald du im Millionenbereich operierst.

Metadaten-Filterung und Hybrid-Suche

In der Praxis reicht reine Vektorsuche selten aus. Du willst meist nicht nur „die ähnlichsten Dokumente", sondern „die ähnlichsten Dokumente aus 2026, auf Deutsch, für Kunde X". Das leistet die Metadaten-Filterung: Du speicherst neben jedem Vektor strukturierte Felder (Datum, Sprache, Kategorie, Zugriffsrechte) und filterst danach.

Der Teufel steckt im Detail. Naives Filtern nach der Vektorsuche führt zum berüchtigten Overfiltering-Problem: Die ANN-Suche liefert zehn Treffer, der Filter wirft neun davon weg, und du sitzt mit einem mageren Ergebnis da. Gute Vektordatenbanken lösen das durch Filterable HNSW oder iterative Index-Scans (pgvector ab 0.8) – der Index wird so lange weiterdurchsucht, bis genügend gefilterte Treffer zusammenkommen. Qdrant und Weaviate gelten 2026 als besonders stark bei gefilterter Suche und behalten selbst mit komplexen Filtern niedrige Latenzen, während andere Systeme dabei um den Faktor 2–3 langsamer werden können.

Der zweite große Trend ist die Hybrid-Suche. Vektorsuche versteht Bedeutung, ist aber bei exakten Begriffen, Produktnummern, Eigennamen oder seltenen Fachwörtern schwächer. Die klassische Keyword-Suche (BM25) ist hier genau umgekehrt stark. Hybrid-Suche kombiniert beide Welten: Sie führt parallel eine Vektor- und eine BM25-Suche aus und verschmilzt die Ergebnisse (z. B. per Reciprocal Rank Fusion). Das Resultat ist robuster als jede Methode allein – und 2026 praktisch ein Pflicht-Feature für ernsthafte RAG-Systeme. Weaviate, Qdrant, Milvus und Elasticsearch bringen Hybrid-Suche nativ mit; bei pgvector kombinierst du es mit Postgres' eingebauter Volltextsuche.

Die wichtigsten Auswahlkriterien

Bevor wir zu den einzelnen Lösungen kommen, hier die Kriterien, an denen sich deine Entscheidung entscheidet:

Self-hosted vs. Managed: Willst du selbst betreiben (volle Kontrolle, DSGVO-freundlich, potenziell günstiger) oder lieber eine Managed Cloud ohne Betriebsaufwand? Das ist die wichtigste Weichenstellung.
Performance & Skalierung: Reden wir über 100.000 Vektoren oder über eine Milliarde? Brauchst du horizontales Sharding und Replikation?
Filterung & Hybrid-Suche: Wie wichtig sind dir komplexe Metadaten-Filter und die Kombination mit Keyword-Suche?
Kosten: Managed-Dienste rechnen sehr unterschiedlich ab – pro Ressource, pro Vektor-Dimension, pro Read/Write-Unit. Die Rechnungen können bei Skalierung stark auseinanderlaufen.
Reife & Ökosystem: Wie stabil ist das Produkt, wie gut die Doku, gibt es Integrationen für LangChain, LlamaIndex & Co.?
„Was habe ich schon?": Wenn du ohnehin Postgres, Redis oder Elasticsearch betreibst, ist die naheliegendste Lösung oft die beste.

Mit diesen Kriterien im Hinterkopf schauen wir uns die Kandidaten an.

Qdrant: der Performance-Spezialist aus Rust

Qdrant (gesprochen „Quadrant") ist 2026 einer der Lieblinge der Community – und das aus gutem Grund. Komplett in Rust geschrieben, mit SIMD-Optimierung und einer eigenen Storage-Engine („Gridstore"), liefert Qdrant herausragende Performance bei gleichzeitig sparsamem Speicherverbrauch dank starker Quantisierung. Im März 2026 sammelte das Unternehmen weitere 50 Mio. US-Dollar ein – ein Signal, dass hier ernsthaft Gas gegeben wird.

Technisch bietet Qdrant eine modifizierte HNSW-Implementierung, exzellente Metadaten-Filterung (Filterable HNSW), native Hybrid-Suche, Named Vectors und Multivector-Workflows sowie saubere REST- und gRPC-APIs. Es lässt sich hervorragend self-hosten (ein einzelner Docker-Container genügt für den Start) und skaliert über Clustering und Replikation horizontal.

Die Qdrant Cloud läuft auf AWS, GCP und Azure und rechnet ressourcenbasiert ab – du zahlst für RAM, vCPU und Disk, nicht pro Query oder Vektor. Es gibt einen dauerhaft kostenlosen Free Tier (0,5 vCPU, 1 GB RAM, 4 GB Disk, ohne Kreditkarte). Eine kleine 2-GB-Instanz liegt grob bei 30–60 US-Dollar pro Monat. Für DSGVO-Setups gibt es zudem eine Hybrid-Cloud-Option, bei der Qdrant auf deiner eigenen Infrastruktur läuft und nur das Management übernimmt.

Stärke: Top-Performance, exzellente Filterung, faires Preismodell, super zum Self-Hosting. Schwäche: Kein eingebautes Vektorisierungs-Modul wie bei Weaviate – du bringst deine Embeddings selbst mit.

Chroma: der König der Prototypen

Chroma ist die Vektordatenbank, mit der die meisten Entwickler ihre erste Berührung haben – und das ist ein Kompliment. Chroma ist darauf ausgelegt, in Sekunden loslegen zu können: pip install chromadb, ein paar Zeilen Python, fertig. Im Embedded-Modus läuft die Datenbank direkt in deinem Prozess (ähnlich wie SQLite), ohne dass du einen Server starten musst. Für Prototypen, lokale Entwicklung und kleinere RAG-Projekte ist das unschlagbar bequem.

2026 hat Chroma deutlich nachgelegt: Chroma Cloud ist eine serverlose, verteilte Variante mit Vektor-, Hybrid- und Volltextsuche, Multi-Region-Replikation, Point-in-time-Recovery und Komfort-Features wie automatischem Crawlen, Chunken und Embedden von Webseiten und GitHub-Repos. Damit wird Chroma erstmals auch für größere Workloads interessant.

Stärke: Genialer Einstieg, minimaler Overhead, tolle Developer Experience. Schwäche: Bei sehr großen Datenmengen (100M+ Vektoren) und höchsten Performance-Ansprüchen stößt Chroma an Grenzen – hier ist es eher „aus seinem Element", wie Benchmarks 2026 zeigen. Die p95-Latenz im Embedded-Modus liegt eher bei 50–100 ms.

pgvector: Vektorsuche direkt in Postgres

Mein persönlicher Geheimtipp für alle, die bereits Postgres einsetzen: pgvector. Das ist keine eigenständige Datenbank, sondern eine Erweiterung für PostgreSQL, die einen vector-Datentyp und ANN-Indizes hinzufügt. Der Charme liegt auf der Hand: Du speicherst deine Vektoren direkt neben deinen relationalen Daten, mit voller ACID-Transaktionssicherheit, gewohnten SQL-Joins, Backups und Point-in-time-Recovery. Kein zweites System, kein zusätzlicher Betriebsaufwand, keine Datensynchronisation.

Die aktuelle Version 0.8.3 unterstützt HNSW- und IVFFlat-Indizes, sechs Distanzmaße (L2, inneres Produkt, Kosinus, L1, Hamming, Jaccard) sowie half-precision-, binary- und sparse-Vektoren. Das große Highlight von Version 0.8 sind iterative Index-Scans, die das oben beschriebene Overfiltering-Problem lösen. Dazu kommen parallele Index-Builds und Quantisierung via halfvec, mit denen du auf einem einzigen Server Millionen von Chunks bewältigst. Benchmarks zeigen Query-Zeiten unter 20 ms bei 1 Mio. Vektoren mit über 95 % Recall. Im 2026er-Ökosystem gibt es zudem DiskANN-basierte Erweiterungen für noch größere Datenmengen.

Praktisch: Jeder Managed-Postgres-Anbieter (Supabase, Neon, AWS RDS, Azure, Google Cloud SQL) unterstützt pgvector. Für die meisten Projekte gilt 2026 der pragmatische Rat: „Du brauchst wahrscheinlich (noch) keine dedizierte Vektordatenbank."

Stärke: Null zusätzliche Infrastruktur, volle SQL-Power, DSGVO-freundlich self-hostbar. Schwäche: Bei sehr hohen Vektor-Volumina und maximalem Durchsatz spielen spezialisierte Engines ihre Stärken aus.

Weaviate: die KI-native Komplettlösung

Weaviate verfolgt einen ganzheitlichen Ansatz: Es ist nicht nur ein Vektorspeicher, sondern eine „AI-native" Datenbank, die Vektorisierung, Hybrid-Suche und generative Anfragen (RAG) direkt eingebaut hat. Du kannst Weaviate deinen Rohtext geben, und es ruft selbstständig ein Embedding-Modell auf, speichert die Vektoren und beantwortet Hybrid-Anfragen aus BM25 + Vektor – alles in einem System. Das macht Weaviate besonders attraktiv, wenn du Hybrid-Suche und schnelle generative Pipelines ohne viel Glue-Code willst.

Bei der Skalierung gehört Weaviate zur Spitzengruppe: Selbst bei 100 Mio. Vektoren hält es den Recall ohne aufwendiges Tuning. Die p95-Latenz liegt bei 30–70 ms (Hybrid-Suche addiert 10–20 ms).

Die Preisgestaltung wurde im Oktober 2025 überarbeitet. Weaviate Cloud Serverless rechnet 2026 nach „Activity Units" (0,095 US-Dollar/AU-Stunde) plus Storage ab; eine 14-tägige Sandbox ist kostenlos, der Einstiegstarif „Flex" beginnt bei rund 45 US-Dollar/Monat. Für 1 Mio. Vektoren mit 1.536 Dimensionen landest du grob bei 45–80 US-Dollar/Monat. Self-hosting ist kostenlos, eine BYOC-Variante (Bring Your Own Cloud) gibt es ebenfalls.

Stärke: Beste eingebaute Hybrid-Suche, native Vektorisierung und RAG, gute Skalierung. Schwäche: Etwas mehr Konzept-Overhead beim Einstieg; das neue Preismodell ist nicht für jeden günstiger geworden.

Pinecone: Managed ohne Kompromisse

Pinecone ist der bekannteste rein Managed-Anbieter – und bewusst kein Open-Source-Produkt zum Self-Hosting. Die Philosophie: Du sollst dich um Embeddings und deine Anwendung kümmern, nicht um Cluster, Sharding oder Index-Tuning. Pinecones serverlose Architektur skaliert automatisch, und selbst bei 100 Mio. Vektoren hält das System den Recall ohne manuelles Nachjustieren.

Die Kehrseite ist der Lock-in und die Abrechnung. Pinecone rechnet serverlos nach Read Units, Write Units und Storage ab. 2026 gibt es vier Tarife: Starter (kostenlos), den neuen Builder ($20/Monat fix), Standard ($50/Monat Mindestumsatz) und Enterprise ($500/Monat Mindestumsatz). Im Standard-Tarif kostet Storage 0,33 US-Dollar/GB, dazu kommen 4,50 US-Dollar pro Million Write Units und 18 US-Dollar pro Million Read Units. Bei kleinen Workloads (1 Mio. Vektoren, typisches RAG) bleibt das mit ein paar Dollar im Monat günstig; bei 10 Mio. Vektoren bist du grob bei ~70 US-Dollar/Monat – und bei großem Durchsatz kann es deutlich teurer werden. Praktiker bemängeln 2026 die teils fehlende granulare Kostenkontrolle.

Stärke: Null DevOps, zuverlässige Skalierung, ausgereift und enterprise-tauglich. Schwäche: Kein Self-Hosting (DSGVO!), Vendor-Lock-in, Kosten können bei Skalierung unangenehm steigen.

Milvus, Redis & Elasticsearch: Spezialisten für besondere Fälle

Milvus ist die populärste Open-Source-Vektordatenbank (über 42.000 GitHub-Sterne) und der Schwergewichtsmeister für Milliarden-Skala. Cloud-native und Kubernetes-freundlich, gibt es dir volle Kontrolle über die Indextypen (IVF, HNSW, SCANN) und sogar GPU-Beschleunigung über NVIDIAs CAGRA. Die Managed-Variante ist Zilliz Cloud; Milvus 2.6.x (GA auf Zilliz Cloud im Januar 2026) bringt bis zu 100-fach schnellere Metadaten-Filterung (JSON-Indexing), Volltextsuche, die laut Anbieter auf bestimmten Datensätzen bis zu 7-mal schneller als Elasticsearch ist, sowie INT8-Vektoren. Eine Milvus-3.0-Vorschau mit Data-Lake-Konzepten erschien im Mai 2026. Die p95-Latenz liegt bei kompetitiven 25–50 ms. Der Preis dieser Mächtigkeit: betriebliche Komplexität – Milvus ist nichts für „mal eben nebenbei".

Redis eignet sich hervorragend, wenn du es ohnehin als Cache betreibst und niedrigste Latenz brauchst. Über RediSearch bietet es FLAT- und HNSW-Indizes, KNN- sowie Range-Queries und die Distanzmaße L2, Kosinus und inneres Produkt. Für Echtzeit-Empfehlungen und semantisches Caching ist Redis ein starker Kandidat – als primärer Massenspeicher für Milliarden Vektoren aber weniger gedacht.

Elasticsearch (und OpenSearch) ist die naheliegende Wahl, wenn du bereits eine Volltextsuche betreibst. Es unterstützt kNN-Suche mit HNSW, Quantisierung und vor allem ausgereifte Hybrid-Suche – die Kombination aus etabliertem BM25 und Vektorsuche ist hier seit Jahren erprobt. Wenn Suche dein Kerngeschäft ist, musst du nicht zwangsläufig ein zweites System einführen.

Die große Vergleichstabelle 2026

Lösung	Typ	Index	Hybrid-Suche	Self-hosting	Managed-Preis (Einstieg)	Skalierung	Ideal für
Qdrant	Dedizierte VektorDB (Rust)	HNSW (modifiziert)	✅ nativ	✅ sehr einfach	Free Tier; ~30–60 $/Mo (2 GB)	hoch (Cluster)	Performance + Self-Hosting
Chroma	Embedded / Cloud	HNSW	✅ (Cloud)	✅ embedded	Serverless, nutzungsbasiert	mittel	Prototypen, lokale Dev
pgvector	Postgres-Erweiterung	HNSW, IVFFlat	➖ via Postgres-FTS	✅ (jeder PG)	Postgres-Hosting-Preis	mittel–hoch	„Schon Postgres im Einsatz"
Weaviate	KI-native VektorDB	HNSW	✅ exzellent	✅ / BYOC	Sandbox gratis; Flex ab ~45 $/Mo	hoch (100M+)	Hybrid-Suche, RAG-Komplettlösung
Pinecone	Managed (serverless)	proprietär	✅	❌	Starter gratis; Builder 20 $/Mo	sehr hoch	Managed ohne DevOps
Milvus	Dedizierte VektorDB	IVF, HNSW, CAGRA (GPU)	✅	✅ (komplex)	Zilliz Cloud, nutzungsbasiert	extrem (Mrd.)	Massive Skalierung
Redis	In-Memory + Vektor	FLAT, HNSW	➖ begrenzt	✅	Redis-Hosting-Preis	mittel	Echtzeit, Caching
Elasticsearch	Such-Engine + Vektor	HNSW	✅ ausgereift	✅	Elastic-Cloud-Preis	hoch	Bestehende Volltextsuche

Die Preisangaben sind grobe Orientierungswerte für kleine Setups (Stand Mitte 2026) und hängen stark von Vektoranzahl, Dimensionen und Query-Volumen ab. Rechne dein konkretes Szenario immer mit dem jeweiligen Pricing-Kalkulator durch.

Welche Vektordatenbank für welchen Anwendungsfall?

Genug Theorie – hier meine klaren Empfehlungen:

Du baust einen Prototyp oder lernst gerade: Nimm Chroma. Schneller bist du nirgends produktiv. Alternativ pgvector, wenn du Postgres schon kennst.
Du betreibst bereits Postgres: Greif zu pgvector. In den allermeisten Fällen brauchst du kein zweites System. Erst wenn du an klare Performance- oder Skalierungsgrenzen stößt, lohnt der Umzug.
DSGVO / Self-Hosting ist Pflicht: Qdrant ist mein Favorit – einfach zu betreiben, performant, fair bepreist. Für deutsche Unternehmen ein idealer Mittelweg. Auch Weaviate (self-hosted/BYOC) und Milvus sind möglich. Mehr zum Thema findest du in meinem Artikel zu LLMs und Datenschutz.
Hybrid-Suche und RAG aus einem Guss: Weaviate glänzt mit nativer Vektorisierung, BM25+Vektor und generativen Queries.
Maximale Skalierung (100M – Milliarden Vektoren): Milvus / Zilliz Cloud, bei Bedarf mit GPU-Indizes. Für Managed ohne jeden Betriebsaufwand: Pinecone.
Du willst dich um nichts kümmern: Pinecone – serverlos, zuverlässig, aber kein Self-Hosting und potenziell teurer bei Wachstum.
Du hast schon Redis oder Elasticsearch: Prüfe zuerst deren Vektor-Funktionen, bevor du ein neues System einführst.

Code-Beispiel: Einfügen und Ähnlichkeitssuche

Genug geredet – schauen wir uns an, wie das in der Praxis aussieht. Hier ein kompaktes Beispiel mit Qdrant in Python: Wir erstellen eine Collection, fügen ein paar Vektoren mit Metadaten ein und führen eine gefilterte Ähnlichkeitssuche durch.

# pip install qdrant-client
from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, PointStruct, Filter,
    FieldCondition, MatchValue,
)

# Lokaler In-Memory-Client zum Ausprobieren (oder url="http://localhost:6333")
client = QdrantClient(":memory:")

# Collection mit 4-dimensionalen Vektoren und Kosinus-Distanz anlegen
client.create_collection(
    collection_name="dokumente",
    vectors_config=VectorParams(size=4, distance=Distance.COSINE),
)

# Drei Dokumente mit Embeddings und Metadaten einfügen
client.upsert(
    collection_name="dokumente",
    points=[
        PointStruct(id=1, vector=[0.10, 0.20, 0.30, 0.40],
                    payload={"titel": "Hund im Garten", "sprache": "de"}),
        PointStruct(id=2, vector=[0.12, 0.18, 0.31, 0.39],
                    payload={"titel": "Welpe auf der Wiese", "sprache": "de"}),
        PointStruct(id=3, vector=[0.90, 0.10, 0.05, 0.02],
                    payload={"titel": "Aktienkurse fallen", "sprache": "de"}),
    ],
)

# Ähnlichkeitssuche: ähnlichste Treffer zum Anfrage-Vektor,
# gefiltert auf deutschsprachige Dokumente
treffer = client.query_points(
    collection_name="dokumente",
    query=[0.11, 0.19, 0.30, 0.40],
    query_filter=Filter(must=[
        FieldCondition(key="sprache", match=MatchValue(value="de"))
    ]),
    limit=2,
).points

for t in treffer:
    print(f"{t.payload['titel']} -> Score: {t.score:.3f}")

Zum Vergleich dasselbe Prinzip mit pgvector in reinem SQL – schön zu sehen, wie nah das an gewohntem Postgres bleibt:

-- Erweiterung aktivieren und Tabelle anlegen
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE dokumente (
    id      bigserial PRIMARY KEY,
    titel   text,
    sprache text,
    embedding vector(4)
);

-- HNSW-Index für schnelle Kosinus-Ähnlichkeitssuche
CREATE INDEX ON dokumente
    USING hnsw (embedding vector_cosine_ops);

-- Daten einfügen
INSERT INTO dokumente (titel, sprache, embedding) VALUES
    ('Hund im Garten',      'de', '[0.10,0.20,0.30,0.40]'),
    ('Welpe auf der Wiese', 'de', '[0.12,0.18,0.31,0.39]'),
    ('Aktienkurse fallen',  'de', '[0.90,0.10,0.05,0.02]');

-- Ähnlichkeitssuche mit Metadaten-Filter
-- (<=> ist der Kosinus-Distanz-Operator)
SELECT titel, 1 - (embedding <=> '[0.11,0.19,0.30,0.40]') AS aehnlichkeit
FROM dokumente
WHERE sprache = 'de'
ORDER BY embedding <=> '[0.11,0.19,0.30,0.40]'
LIMIT 2;

In beiden Fällen liefern „Hund im Garten" und „Welpe auf der Wiese" die besten Scores, während „Aktienkurse fallen" trotz desselben Sprach-Filters weit abgeschlagen ist – genau wie es sein soll. In der Realität haben deine Vektoren natürlich 768, 1.024 oder 1.536 Dimensionen statt vier, aber das Prinzip bleibt identisch.

Was davor und danach kommt

Eine Vektordatenbank ist ein Baustein, kein Selbstzweck. Davor steht die Frage, wie aus Text überhaupt Vektoren werden — das erkläre ich in Embeddings verständlich erklärt. Danach steht meist eine vollständige Abrufstrecke, beschrieben in RAG selbst bauen.

Und ein Punkt, der die Auswahl relativiert: Der Wechsel der Datenbank ist billiger als der Wechsel des Embedding-Modells. Das eine bedeutet Umziehen, das andere Neuberechnen. Wer sich also lange mit der Datenbankwahl aufhält und das Embedding-Modell nebenbei entscheidet, gewichtet falsch herum.

Wer alles lokal betreiben will, findet den Unterbau in Ollama: lokale Sprachmodelle betreiben und die Modellauswahl in Welches Ollama-Modell?.

Zusammenfassung und praktische Tipps

Fassen wir zusammen. Vektordatenbanken speichern Embeddings und finden per ANN-Suche blitzschnell die bedeutungsähnlichsten Treffer. Das Herzstück sind Indizes wie HNSW (Standard) und IVF, kombiniert mit Distanzmaßen, Metadaten-Filterung und immer häufiger Hybrid-Suche aus Vektor + BM25. Der Markt 2026 ist reif und vielfältig – die „beste" Datenbank gibt es nicht, nur die beste für deinen Fall.

Meine wichtigsten Praxis-Tipps:

Fang klein an. Für die meisten Projekte sind pgvector (wenn du Postgres hast) oder Chroma (für Prototypen) die pragmatischste Wahl. Wechsle erst, wenn du nachweisbar an Grenzen stößt.
Self-hosting für DSGVO: Qdrant ist 2026 mein Top-Tipp für deutsche Unternehmen – einfach, schnell, fair bepreist.
Miss deine eigene Performance. Verlass dich nicht auf Hersteller-Benchmarks. Recall und Latenz hängen massiv von deinen Daten, Dimensionen und Filtern ab.
Plane die Hybrid-Suche von Anfang an mit ein, wenn deine Anwendung mit Eigennamen, Produktnummern oder Fachbegriffen zu tun hat.
Achte auf die Kosten-Fallen. Managed-Dienste rechnen sehr unterschiedlich ab; rechne dein konkretes Volumen vorher durch, sonst überrascht dich die Rechnung.
Quantisierung spart Geld, sobald du im Millionenbereich operierst – probier es aus, der Qualitätsverlust ist meist minimal.

Egal, für welche Lösung du dich entscheidest: Du baust gerade auf einer der spannendsten Infrastruktur-Schichten der KI-Ära. Viel Spaß beim Vektorisieren!

Vektordatenbanken im Vergleich 2026: Qdrant, Chroma, pgvector, Weaviate, Pinecone & Co.

Vektordatenbanken im Vergleich 2026: Qdrant, Chroma, pgvector, Weaviate, Pinecone & Co.

Artikel-Übersicht

Einleitung: Warum 2026 alle über Vektordatenbanken reden

Wozu eine Vektordatenbank? Embeddings und Ähnlichkeitssuche

Wie Vektordatenbanken funktionieren: Indizes und Distanzmaße

Metadaten-Filterung und Hybrid-Suche

Die wichtigsten Auswahlkriterien

Qdrant: der Performance-Spezialist aus Rust

Chroma: der König der Prototypen

pgvector: Vektorsuche direkt in Postgres

Weaviate: die KI-native Komplettlösung

Pinecone: Managed ohne Kompromisse

Milvus, Redis & Elasticsearch: Spezialisten für besondere Fälle

Die große Vergleichstabelle 2026

Welche Vektordatenbank für welchen Anwendungsfall?

Code-Beispiel: Einfügen und Ähnlichkeitssuche

Was davor und danach kommt

Zusammenfassung und praktische Tipps

Ressourcen