Vektordatenbank

Definition und Praxis-Bezug

Eine Vektor-Datenbank (auch Vector Database, Vector Store) ist ein spezialisiertes Datenbanksystem, das hochdimensionale Vektoren — typischerweise Embeddings mit 384 bis 3.072 Dimensionen — speichert, indiziert und schnell durchsucht. Klassische SQL-Datenbanken suchen exakte Werte; Vector-DBs finden die "ähnlichsten" Vektoren über Distanz- oder Winkelmetriken wie Cosine Similarity, Dot Product oder Euclidean Distance.

In der Praxis sind Vector-Datenbanken das Fundament jeder produktiven RAG-Pipeline, jeder semantischen Suche, jedes modernen Empfehlungssystems. Ohne Vector-DB skaliert RAG nicht über ein paar tausend Dokumente hinaus — mit Vector-DB sind hunderte Millionen Dokumente in Millisekunden durchsuchbar. 2026 sind sie ein Standard-Baustein moderner KI-Stacks.

Wie speichern Vector-DBs Embeddings?

Naiv würde man jeden Query-Vektor mit allen gespeicherten Vektoren vergleichen — bei 10 Millionen Vektoren à 1.536 Dimensionen wären das pro Suche 15 Milliarden Multiplikationen. Das skaliert nicht. Vector-DBs nutzen deshalb Approximate Nearest Neighbor (ANN) Algorithmen, die mit minimaler Genauigkeitseinbuße um Faktoren von 100–1.000 schneller sind.

Die wichtigsten Algorithmen 2026: HNSW (Hierarchical Navigable Small World) baut einen mehrschichtigen Graphen aus Vektoren — Suche springt zwischen Layern, findet schnell die Region und dann den nächsten Nachbarn. IVF (Inverted File Index) clustert Vektoren in Voronoi-Zellen, sucht nur in den relevanten Clustern. PQ (Product Quantization) komprimiert Vektoren in kleine Codes — 32x weniger Speicher bei moderatem Qualitätsverlust. DiskANN ermöglicht Suche auf SSD statt RAM und macht Milliarden-Skalen wirtschaftlich.

Moderne Vector-DBs kombinieren mehrere Verfahren: Filterung nach Metadaten (z. B. nur Dokumente eines Mandanten), Hybrid Search mit BM25, Multi-Tenant-Isolation, Replikation, Backups und ACL. Sie sind in der Architektur näher an Search-Engines (Elasticsearch) als an klassischen SQL-DBs.

Top 5 Vektor-Datenbanken 2026

1. Pinecone — der Managed-Service-Marktführer. Serverless, blitzschnelles Onboarding, Auto-Scaling, gute SDKs. Nachteil: kein Self-Hosting, Vendor-Lock-in, ab Volumen teuer. Beste Wahl für schnellen Production-Launch ohne DevOps.

2. Qdrant — Open Source in Rust, sehr performant, hervorragende Filter-Performance. Self-Hosting und Managed Cloud verfügbar. Beste Wahl für Self-Hosting in der EU mit hohen Performance-Ansprüchen. 2026 die häufigste Wahl für Production-Setups.

3. Weaviate — Open Source, modular (eingebaute Vectorization, Generative Modules, Multi-Modal). GraphQL-API. Beste Wahl für komplexe Setups mit verschiedenen Modalitäten und tight integration mit LLMs.

4. Chroma — schlank, Python-first, perfekt für Prototypen und kleine bis mittlere Setups. Embedded oder Server-Mode. Beste Wahl für Notebook-Entwicklung und schnelle Proof-of-Concepts.

5. Milvus — Hyperscale-fähig, Cloud-Native, GPU-Acceleration. Beste Wahl ab 100 Millionen Vektoren. Etwas komplexer im Setup, skaliert dafür am besten bei großen Volumen.

Honorable Mentions: pgvector (PostgreSQL-Extension), Vespa (Yahoo, Enterprise-Search), Turbopuffer (serverless, SSD-first, sehr günstig), LanceDB (embedded, columnar).

Anwendungsfälle KMU und Enterprise

KMU: RAG-Chatbots für Kundenservice, semantische Produktsuche im Shop, interne Wissens-Suche über Notion, Confluence oder Sharepoint, Duplicate Detection in CRM-Daten. Typische Größe: 10.000 bis 5 Millionen Vektoren. Wahl: meist Qdrant Self-Hosted oder Pinecone Starter.

Enterprise: Konzernweite Knowledge-Bases mit 50M+ Dokumenten, Multi-Mandanten-Setups mit ACL, Hybrid Cloud Deployments, Echtzeit-Empfehlungssysteme für E-Commerce mit Milliarden Items, Personalisierungs-Engines im Streaming. Wahl: Milvus oder Weaviate Enterprise. Mehr Details in unserer KI-Implementierung.

Best Practices

1. Index-Parameter zur Use-Case-Passung tunen. HNSW M=16 und efConstruction=200 sind gute Defaults — für höchste Qualität M=64, für Speed M=8.

2. Metadaten-Filter nutzen. Filter auf Datum, Tenant, Kategorie reduzieren den Suchraum drastisch und sparen Kosten.

3. Embeddings normalisieren. L2-normalisierte Vektoren erlauben Dot Product statt Cosine, signifikant schneller.

4. Quantisierung erwägen. Binary Quantization oder Scalar Quantization sparen 4–32x Speicher mit minimalem Recall-Verlust.

5. Hybrid Search aktivieren. Reiner Vector-Search liefert bei Eigennamen, Produkt-IDs oder Codes oft schlechte Ergebnisse — BM25-Komponente schließt diese Lücke.

Vergleichstabelle

Pinecone: Managed only, einfach, schnell, teurer ab Volumen, kein Self-Hosting. Qdrant: Open Source, Self-Hosting + Cloud, sehr performant, gute Filter-Engine, EU-Hosting möglich. Weaviate: Open Source, modular, Multi-Modal, GraphQL, komplexer im Setup. Chroma: Open Source, Embedded-First, Python-zentriert, ideal für Dev. Milvus: Open Source, Hyperscale, GPU-Support, schwerer aufzusetzen. pgvector: Postgres-Extension, einfache Integration in bestehende Stacks, bis ca. 1M Vektoren stark.

Performance, HNSW und Hybrid-Search

Realistische Performance-Werte für 10M Vektoren mit 1.536 Dimensionen auf einer 32-GB-RAM-Maschine: HNSW bei Recall@10 = 95 Prozent: 2–8 ms pro Query. IVF-PQ bei Recall@10 = 90 Prozent: 5–15 ms, aber 10x weniger RAM. DiskANN auf SSD: 20–80 ms, aber Milliarden Vektoren pro Knoten möglich. Hybrid Search fügt typischerweise 5–15 ms hinzu, steigert die Trefferquote aber oft um 20–35 Prozent — für Production fast immer die richtige Wahl. Mehr zu praxisreifen Setups in unserer KI-Beratung und unter LangChain für Orchestrierung.