Vektordatenbanken im Vergleich: pgvector, Qdrant, Chroma, Weaviate

Was ist eine Vektordatenbank?

Eine Vektordatenbank speichert Embedding-Vektoren — typisch 384 bis 3.072 Dimensionen — und bietet eine Kernoperation: für einen Anfrage-Vektor möglichst schnell die ähnlichsten gespeicherten Vektoren finden.

Die wichtigsten Distanzmaße sind Cosine Similarity, Euclidean und Dot Product. Für schnelle Suche bei Millionen Vektoren kommen spezielle Indizes zum Einsatz — allen voran HNSW (Hierarchical Navigable Small World).

Alle fünf hier vorgestellten Datenbanken unterstützen HNSW. Der Unterschied liegt in Betrieb, Features, Skalierbarkeit und Integrationsaufwand.

Die fünf Kandidaten im Überblick

flowchart TD
  Start["Projekt startet"] --> Q1{"Schon PostgreSQL?"}
  Q1 -->|Ja| PG["pgvector"]
  Q1 -->|Nein| Q2{"Prototyp oder Produktion?"}
  Q2 -->|Prototyp| CH["Chroma"]
  Q2 -->|Produktion| Q3{"Hybrid-Suche?"}
  Q3 -->|Ja| WV["Weaviate"]
  Q3 -->|Nein| Q4{"> 10M Vektoren?"}
  Q4 -->|Nein| PG
  Q4 -->|Ja| Q5{"> 100M, Multi-Tenant?"}
  Q5 -->|Nein| QD["Qdrant"]
  Q5 -->|Ja| ML["Milvus"]

pgvector — der PostgreSQL-Veteran

pgvector ist eine PostgreSQL-Extension. Zwei SQL-Befehle, und die bestehende PostgreSQL-Installation wird zur Vektordatenbank. Seit Version 0.5 mit vollem HNSW-Support, seit 0.7 deutlich schnellere Indexierung.

Stärken: ein System weniger (kein separates Backup/Monitoring), SQL-Joins zwischen Metadaten und Vektoren, transaktional, bekannte Betriebswerkzeuge.

Grenzen: maximal 2.000 Dimensionen; bei Query-Last jenseits mehrerer Millionen Vektoren fällt Latenz im Vergleich zu spezialisierten DBs ab. Für die meisten Mittelstandsprojekte völlig unkritisch.

Qdrant — der Rust-Performant

Qdrant ist in Rust geschrieben, läuft als eigenständiger Dienst, derzeit einer der schnellsten Vector-Stores. REST- und gRPC-APIs, exzellentes Payload-Filtering (echte Pre-Filter-Suche), Scalar- und Binary-Quantization.

Stärken: Top-Performance, bis zu 32× kleinere Indizes durch Quantization, gute Cloud-und-Self-Hosting-Dokumentation.

Grenzen: zusätzliche Komponente im Stack. Wer bereits PostgreSQL betreibt, muss ein weiteres System lernen.

Chroma — der Prototyping-Liebling

Chroma ist Python-first, sehr schlankes SDK, läuft im Embedded-Modus (SQLite) oder als Server. Von pip install bis zu ersten Ergebnissen vergehen Minuten.

Stärken: niedrigste Einstiegshürde, Embedded-Modus (keine DB nötig), ideal für Jupyter-Notebooks.

Grenzen: Skalierungs-Story bleibt 2026 schwach. Ab ca. einer Million Vektoren oder unter hoher Last nicht reif genug für Produktion.

Weaviate — der Hybrid-Suche-Spezialist

Weaviate kombiniert Vektorsuche mit klassischer BM25-Keyword-Suche — Hybrid-Suche out of the box. GraphQL-API, Modulsystem (Embeddings, Reranking), Multi-Tenant-Support.

Stärken: Hybrid Search — besonders bei kurzen Queries mit Eigennamen deutlich besser als reine Vektorsuche. Modulares Ökosystem.

Grenzen: steilere Lernkurve. GraphQL-API ist Geschmackssache. Größerer Stack als pgvector oder Qdrant.

Milvus — der Cloud-Native-Skaler

Milvus ist in C++ geschrieben, für Milliarden-Skalen gebaut. Mehrere Komponenten (Etcd, MinIO, Pulsar, verschiedene Nodes) skalieren unabhängig. Fluch und Segen: enormes Potenzial, hoher Betriebsaufwand.

Stärken: horizontale Skalierung in den zweistelligen Milliardenbereich, natives Multi-Tenancy, auf Kubernetes zugeschnitten.

Grenzen: für 99 % der Mittelstandsprojekte Overkill. Betrieb erfordert ein erfahrenes Platform-Team.

Entscheidungsmatrix

Die kurze Antwort nach Projekt-Profil:

• Einzel-Agent, ein Team, < 1 M Vektoren: pgvector
• Prototyp, Jupyter, schnelle Iteration: Chroma
• Produktiver RAG-Service mit viel Traffic: Qdrant
• Technische Dokumentation, E-Commerce-Suche: Weaviate (Hybrid-Suche lohnt sich bei Eigennamen und Modellnummern)
• SaaS-Plattform, Mandantentrennung, > 100 M Vektoren: Milvus

Eine zweite Faustregel: Start mit pgvector, wechsle erst bei messbarer Grenze. Der teuerste Fehler ist, gleich mit Qdrant oder Milvus zu starten.

Fazit

2026 sind Vektordatenbanken ein gelöstes Problem — es gibt keine schlechte Wahl, nur unpassende Wahl zum Projekt. Die wichtigste Entscheidung ist nicht „welche ist die beste", sondern „welche passt zu meinem Stack und meiner Größenordnung".

Mein Rat: Wenn du PostgreSQL hast, nimm pgvector. Wenn nicht und es produktiv werden soll, Qdrant. Alle anderen sind Spezialfälle mit klaren Triggern.