Vector Database (Vektordatenbank)

Eine Vector Database (Vektordatenbank) ist eine Datenbank, die auf Ähnlichkeitssuche über Embeddings spezialisiert ist, also über Zahlenlisten (Vektoren), die ein KI-Modell aus Texten, Bildern oder Audio erzeugt und in denen inhaltlich ähnliche Objekte auch geometrisch nahe beieinander liegen. Zu einem Anfrage-Vektor liefert sie in Millisekunden die ähnlichsten Treffer aus dem Bestand, über sogenannte Approximate-Nearest-Neighbor-Verfahren (ANN, „annähernde Nachbarschaftssuche"; Verfahren wie HNSW, IVF, IVF-PQ, DiskANN). Sie bildet den Suchspeicher hinter [semantischer Suche](/insights/glossar/semantic-search/), [RAG-Anwendungen](/insights/glossar/rag/) (Retrieval-Augmented Generation, Sprachmodelle mit Firmenwissen-Anbindung), Empfehlungssystemen und Bild-/Audio-Suche.

Was ist eine Vector Database?

Eine Vector Database speichert jeden Datensatz als Paar aus einem Vektor und begleitenden Metadaten. Der Vektor ist ein [Embedding](/insights/glossar/embeddings/), also eine Zahlenliste fester Länge (typisch 384 bis 4.096 Kommazahlen), die ein [Embedding-Modell](/insights/glossar/embedding-models/) aus Text, Bild, Audio oder anderen Inhalten berechnet hat und die die Bedeutung des Ausgangsobjekts als Punkt in einem geometrischen Raum abbildet. Die Metadaten enthalten den Originaltext beziehungsweise Verweise darauf, Herkunft, Zeitstempel und filterbare Angaben wie Sprache, Mandant oder Dokumenttyp. Kern jeder Vector Database ist ein Index, der zu einem Anfrage-Vektor die k ähnlichsten Vektoren nach einem Abstandsmaß (Cosinus, Skalarprodukt, euklidischer Abstand) zurückliefert, ohne den Bestand Vektor für Vektor durchgehen zu müssen.

Der zentrale technische Baustein ist die Approximate Nearest Neighbor Search (ANN). Eine exakte kNN-Suche vergleicht den Query-Vektor mit jedem Vektor im Bestand und skaliert linear mit dessen Größe, was bei Millionen bis Milliarden Vektoren praktisch nicht mehr trägt. ANN-Indexe geben eine minimale Trefferunschärfe (typisch 95 bis 99 Prozent Recall) auf und liefern dafür Latenzen im einstelligen Millisekunden-Bereich. Verbreitete Verfahren sind Hierarchical Navigable Small World Graphs ([HNSW](https://arxiv.org/abs/1603.09320)), invertierte Datei-Verfahren mit Produktquantisierung (IVF-PQ), Locality Sensitive Hashing und graphenbasierte SSD-Ansätze wie [DiskANN](https://suhasjs.github.io/files/diskann_neurips19.pdf). Die Wahl des Verfahrens bestimmt das Verhältnis aus Speicherbedarf, Ingest-Kosten, Query-Latenz und Recall.

Der Begriff hat sich durchgesetzt, weil bestehende Datenbanken für Vektor-Retrieval strukturell nicht gebaut waren. Relationale Systeme sind auf exakte Übereinstimmungen und Joins ausgelegt, invertierte Volltext-Indexe auf Token-Statistik, Feature Stores auf gepflegte ML-Features für Training und Inferenz. Keiner dieser Indextypen beantwortet die Frage „Welche 20 Vektoren im Bestand liegen dem Query-Vektor geometrisch am nächsten?" in Sub-100-Millisekunden über Millionen Datensätze. Vector Databases schließen diese Lücke. Sie sind mit dem Aufstieg dichter Embedding-Modelle und produktiver [RAG-Anwendungen](/insights/glossar/rag/) zwischen 2022 und 2024 zur eigenen Systemklasse geworden.

Über die reine ANN-Suche hinaus decken produktive Vector Databases weitere Funktionen ab. Sie unterstützen Metadaten-Filter (etwa nach Mandant, Sprache oder Zeitraum), damit die Suche nicht über den gesamten Bestand läuft. Sie kombinieren Vektor-Retrieval mit lexikalischer Suche (BM25 oder Sparse-Vektoren) zu [Hybrid Search](/insights/glossar/hybrid-search/). Sie bieten Namensräume oder Kollektionen für Mandantenfähigkeit, Zugriffssteuerung über Rollen oder Attribute sowie inkrementellen Ingest für häufig aktualisierte Dokumentbestände. Managed-Angebote koppeln den Index eng an ein Table-Format des zugrundeliegenden Data Lakehouse und synchronisieren Vektoren automatisch bei Datenänderungen.

Zum Marktumfeld gehören dedizierte Vector-Native-Systeme wie Pinecone, [Weaviate](https://weaviate.io/developers/weaviate), [Milvus](https://milvus.io/docs), Qdrant und Chroma sowie Erweiterungen bestehender Datenbanken, etwa pgvector für PostgreSQL, Redis Vector, Elasticsearch und OpenSearch mit kNN-Index, MongoDB Atlas Vector Search und SingleStore. Als Managed-Angebot in einer Data-Plattform bietet Databricks Mosaic AI Vector Search Vektor-Indexe direkt auf Unity-Catalog-Tabellen an. AWS OpenSearch Service, Azure AI Search und Google Vertex AI Vector Search decken denselben Anwendungsraum auf den großen Hyperscalern ab.

Abgrenzung zu Vector Search, Relational Database, Search Engine und Feature Store

Der Begriff wird regelmäßig mit angrenzenden Systemtypen und mit seinem eigenen Suchvorgang vermischt. Die Abgrenzung sitzt jeweils an einer klaren funktionalen Grenze.

Der Unterschied zu Vector Search ist der zwischen System und Vorgang. Vector Search bezeichnet den Suchvorgang selbst, also die Approximate-Nearest-Neighbor-Abfrage über Embeddings, oder ein Feature innerhalb einer bestehenden Plattform (etwa KNN in Elasticsearch, VECTOR_SEARCH in Snowflake). Eine Vector Database ist das eigenständige System, das diesen Vorgang skalierbar umsetzt, mit Index-Verwaltung, Metadaten-Filtern, Ingest-Pfaden, Zugriffssteuerung und Betrieb. In der Praxis werden beide Begriffe häufig austauschbar verwendet, technisch bezeichnet der eine die Funktion, der andere das Produkt. Ein PostgreSQL mit pgvector bietet Vector Search als Erweiterung, ohne im engeren Sinn eine Vector-Native-Database zu sein.

Der Unterschied zu einer [relationalen Datenbank](/insights/glossar/relational-database/) ist der zwischen Ähnlichkeit und exakter Übereinstimmung. Eine relationale Datenbank speichert typisierte Zeilen in Tabellen und beantwortet SQL-Anfragen mit exakten Filtern, Joins und Aggregationen unter [ACID](/insights/glossar/acid-transactions/)-Garantien. Der Standardindex ist der B-Tree, optional Hash- oder GiST-Index. Eine Vector Database beantwortet Ähnlichkeitsfragen über Embeddings unter Toleranz für minimale Trefferunschärfe. Der Standardindex ist HNSW oder IVF-PQ. Beide Systeme sind komplementär und in produktiven KI-Stacks parallel im Einsatz: die relationale Datenbank für transaktionale Anwendungsdaten und Metadaten, die Vector Database für den semantischen Retrieval-Pfad. Postgres mit pgvector verbindet beide Rollen in einem System, gibt aber gegenüber Vector-Native-Systemen Skalierungsspielraum bei sehr großen Beständen und hohem Ingest-Durchsatz auf.

Der Unterschied zu einer Search Engine ist der zwischen Bedeutung und Zeichenkette. Klassische Suchmaschinen wie Elasticsearch, OpenSearch, Solr oder Vespa arbeiten mit einem invertierten Index über Volltext-Feldern. Die Ranking-Funktion (BM25 oder TF-IDF) bewertet nach Term-Frequenz und inverser Dokument-Frequenz. Sie finden exakte Termübereinstimmungen und deren Stamm-Formen, verfehlen aber Synonyme und Paraphrasen. Eine Vector Database rankt umgekehrt nach geometrischer Nähe im Embedding-Raum und deckt damit Synonyme, Umschreibungen und multimodale Anfragen ab, verfehlt aber exakte Bezeichner wie Produktcodes oder Ticketnummern. Moderne Suchmaschinen bieten inzwischen kNN-Indexe an und verwischen die Grenze; wer die Vektor-Funktion nutzt, betreibt in dieser Rolle eine Vector Database. In produktiven Retrieval-Stacks werden beide Ansätze zu [Hybrid Search](/insights/glossar/hybrid-search/) kombiniert.

Der Unterschied zu einem [Feature Store](/insights/glossar/feature-store/) ist der zwischen ML-Feature-Verwaltung und Ähnlichkeitssuche. Ein Feature Store verwaltet vorberechnete ML-Features (Aggregate, Zeitfenster, Kunden-Kennzahlen), stellt sie konsistent im Training und in der Online-Inferenz bereit und sorgt für Punkt-in-Zeit-Korrektheit. Der Zugriff erfolgt über Schlüssel wie customer_id und liefert exakte Feature-Werte für eine Modell-Inferenz. Eine Vector Database verwaltet Embeddings und liefert die nächsten Nachbarn zu einem Query-Vektor. Der Zugriffsschlüssel ist der Vektor selbst, die Antwort ist eine geordnete Kandidatenliste. Beide Systeme können in derselben KI-Anwendung nebeneinander stehen: der Feature Store liefert die harten Features für ein Scoring-Modell, die Vector Database das semantische Retrieval für eine RAG-Antwort.

Beispiel: Vector Database als Retrieval-Backend eines Wissensassistenten

Eine Konzernabteilung betreibt einen internen Wissensassistenten über 500.000 Textabschnitte aus PDF-Verträgen, technischen Handbüchern, Confluence-Seiten und Support-Tickets. Nach dem [Chunking](/insights/glossar/chunking/) läuft jeder Abschnitt durch das Embedding-Modell bge-large-en-v1.5. Ergebnis: 500.000 Embeddings mit je 1.024 Dimensionen. Der reine Vektor-Speicherbedarf liegt bei rund 2 GB (500.000 mal 1.024 mal 4 Byte), plus Chunk-Text und Metadaten. Diese Embeddings landen in einer Vector Database, etwa Qdrant oder Databricks Mosaic AI Vector Search, indiziert per HNSW mit m=16 und ef_construction=200.

Zur Query-Zeit erzeugt dasselbe Modell aus der Nutzerfrage ein Query-Embedding. Die Vector Database durchsucht den HNSW-Index nach den zehn Vektoren mit der höchsten Cosinus-Ähnlichkeit, gefiltert auf Metadaten wie Mandant, Dokumentklasse und Sprache. Die Antwortzeit liegt bei etwa 15 Millisekunden über den gesamten Bestand, statt mehreren Sekunden für eine exakte kNN-Suche. Die Top-10-Kandidaten laufen anschließend durch einen [Reranker](/insights/glossar/reranking/); die Top-3 dienen einem Sprachmodell als Kontext für die Antwortformulierung.

Der Betrieb bringt drei charakteristische Aufgaben mit sich, die eine relationale Datenbank oder Search Engine so nicht abbildet. Erstens die Bindung zwischen Embeddings und Erzeuger-Modell: ein Wechsel des Embedding-Modells (etwa von bge-large auf voyage-3) macht alle bestehenden Vektoren im Index unbrauchbar, weil die neuen Vektoren in einem anderen semantischen Raum liegen. Der vollständige Neu-Ingest ist Pflicht. Zweitens die Wahl der Index-Parameter: höhere m- und ef_search-Werte bei HNSW verbessern Recall auf Kosten von Speicher und Latenz, IVF-PQ komprimiert Vektoren stark und verbilligt Speicher, verliert dafür aber Trennschärfe. Drittens die Synchronisation mit der Wahrheitsquelle: Ändert sich ein Dokument im Vertragsspeicher, muss der zugehörige Chunk neu embedded und im Vektor-Index ersetzt werden. Managed-Angebote wie Databricks Mosaic AI Vector Search automatisieren diesen Ingest über Change-Data-Feed auf dem Lakehouse; eigenbetriebene Systeme erfordern eine eigene Ingest-Pipeline.