Eine Vektordatenbank ist eine Datenbank, die für das Speichern und Abfragen hochdimensionaler Vektoren (Embeddings) mittels Ähnlichkeitssuche statt exakter Übereinstimmung optimiert ist. Sie liefert die nächsten Treffer auf Basis von Kosinus-Ähnlichkeit, Skalarprodukt oder euklidischem Abstand und macht damit RAG, semantische Suche sowie KI-native Debitorenprozesse erst in großem Umfang möglich.
Eine Vektordatenbank ist für eine ganz bestimmte Aufgabe gebaut: Sie speichert hochdimensionale numerische Vektoren (typischerweise Embeddings mit 384 bis 3.072 Dimensionen) und findet diejenigen, die einem Anfragevektor am ähnlichsten sind. Statt zu fragen Ist dieser Datensatz gleich jenem Wert, fragen Sie Welche Datensätze liegen diesem Punkt im Vektorraum am nächsten. Die Nähe messen Sie über Kosinus-Ähnlichkeit, Skalarprodukt oder euklidischen Abstand.
Relationale Datenbanken tun sich damit schwer, denn B-Baum-Indizes funktionieren nur für eindimensionale, geordnete Schlüssel. Keyword-Suchmaschinen wie Elasticsearch gleichen lexikalisch hervorragend ab, verstehen aber nicht, dass die Rechnung war falsch und Preisstreitigkeit dasselbe bedeuten. Eine Vektordatenbank schließt diese Lücke, indem sie Bedeutung indexiert statt exakter Tokens. Genau das ist die Voraussetzung für jedes KI-native Retrieval-Muster.
Millionen gespeicherter Vektoren per Brute-Force gegen einen Abfragevektor zu prüfen, ist für den Produktivbetrieb zu langsam. Vektordatenbanken setzen deshalb auf ANN-Indizes (Approximate Nearest Neighbour). Diese nehmen einen geringen Verlust bei der Trefferquote (Recall) in Kauf und gewinnen dafür enorm an Geschwindigkeit.
Außerdem wählen Sie ein Distanzmaß. Bei den meisten Embedding-Modellen ist die Kosinus-Ähnlichkeit die Standardwahl, denn sie ignoriert den Betrag und achtet nur auf die Richtung. Das Skalarprodukt arbeitet bei normalisierten Vektoren schneller. Der euklidische Abstand passt bei modernen Text-Embeddings nur selten.
Der Markt ist inzwischen so ausgereift, dass es bei der Wahl selten um die reine Leistungsfähigkeit geht, sondern eher darum, was betrieblich zu Ihnen passt.
Für ein Debitoren- oder O2C-Team liegt der Wert einer Vektordatenbank nicht in der Technologie selbst, sondern in dem, was sie möglich macht.
Vektordatenbanken wirken simpel, bis sie in den Produktivbetrieb gehen. Einige Dinge holen Teams in den ersten 90 Tagen ein.
Für die meisten Finanzorganisationen führt der pragmatische Weg über einen einfachen Einstieg: Starten Sie mit pgvector, wenn Sie ohnehin schon Postgres betreiben. So liegt die Vektorsuche direkt neben Ihren Kundenstamm- und Rechnungstabellen, und es gelten dieselben Standards für Backup, Zugriffskontrolle und Compliance, auf die Sie sich längst verlassen. Auf eine dedizierte Vektordatenbank wechseln Sie erst, wenn Abfragelatenz, Vektoranzahl oder spezialisierte Funktionen (anspruchsvolle Hybridsuche, sehr große Skalierung) es erfordern.
Die Fallstricke, an denen Projekte scheitern, wiederholen sich fast immer: Die Dimensionen weichen nach einem Modell-Upgrade voneinander ab, das Distanzmaß passt nicht zum eingesetzten Embedding-Modell, die Metadatenfilterung fehlt, sodass das System mit wachsendem Umfang irrelevante Textabschnitte abruft, niemand überwacht Recall und Latenz kontinuierlich, und die Betriebskosten für Backup und Wiederherstellung werden unterschätzt (beides fällt deutlich schwerer als bei SQL). Behandeln Sie die Vektordatenbank vom ersten Tag an als produktive Infrastruktur, nicht als Notebook-Experiment, das zufällig im Livebetrieb läuft.
Sobald Sie mehr tun als einen einzelnen Prompt an ein LLM zu senden (etwa RAG über Ihre Verträge, semantische Suche in der Streitfallhistorie oder agentische Workflows, die vor jeder Aktion erst den passenden Kontext abrufen), dann ja. Die Vektordatenbank sorgt dafür, dass die KI den richtigen Ausschnitt Ihrer Daten findet, bevor sie antwortet. Ohne sie beschränken Sie sich auf das, was in das Kontextfenster des Modells passt, und das skaliert nicht für einen realen Dokumentenbestand im Unternehmen.
Oft ja. Die Erweiterung pgvector ergänzt Postgres um Vektorspalten sowie HNSW-/IVF-Indizes, und für viele Finanzteams ist das der richtige Einstieg. Sie halten die Vektoren direkt neben Ihren strukturierten Daten, nutzen bestehende Backups und Zugriffssteuerungen weiter und ersparen sich den Betrieb eines zweiten Systems. Eine dedizierte Vektordatenbank brauchen Sie in der Regel erst, wenn Sie Postgres bei Umfang oder Latenz entwachsen oder eine sehr fortgeschrittene hybride Suche benötigen.
Elasticsearch ist für die Stichwort- und Volltextsuche mit invertierten Indizes gebaut. Es glänzt, wenn die Suchanfrage des Nutzers Wörter mit dem Dokument teilt. Eine Vektordatenbank sucht dagegen nach Bedeutung und findet so Dokumente, die inhaltlich verwandt sind, selbst wenn die Formulierung völlig anders ausfällt. Modernes Elasticsearch beherrscht inzwischen die Vektorsuche, und die meisten Vektordatenbanken können mittlerweile auch die Stichwortsuche, sodass die Grenzen verschwimmen. Die hybride Suche (beides gleichzeitig) ist im Produktivbetrieb der Idealfall.
HNSW bietet geringere Abfragelatenz und höhere Trefferquote, verbraucht aber mehr Speicher und baut sich langsamer auf. IVF benötigt weniger Speicher und ist schneller aufgebaut, hat bei gleicher angestrebter Trefferquote aber meist eine etwas höhere Abfragelatenz. Für die meisten Anwendungsfälle in der Debitorenbuchhaltung (Hunderttausende bis wenige Millionen Vektoren, Ziel unter 100 ms Latenz) ist HNSW die Standardwahl. IVF oder IVF plus Produktquantisierung wird bei sehr großem Umfang interessant oder wenn die Speicherkosten dominieren.
Die Kosten entstehen an drei Stellen: bei der Speicherung von Vektoren und Index, beim Abfragevolumen und (bei Managed Services) bei einer Plattform-Grundgebühr. Als grobe Größenordnung sollten Sie für einige Hunderttausend Vektoren bei einem Managed Service mit einem zwei- bis niedrigen dreistelligen Eurobetrag pro Monat rechnen, wobei die Kosten ungefähr linear mit der Vektoranzahl steigen. Selbst gehostetes pgvector oder Qdrant auf einer bestehenden Cloud-Datenbank kann in kleinem Umfang faktisch kostenlos sein, abgesehen von der zugrunde liegenden Rechenleistung. Machen Sie stets einen Benchmark mit Ihren realen Embedding-Dimensionen, bevor Sie sich festlegen.
Zu jedem Vektor nicht genügend Metadaten zu speichern. Ohne Felder wie Kundennummer, Dokumententyp, Region und Datum lässt sich die Suche nicht filtern, und die Datenbank liefert bereitwillig den global ähnlichsten Textabschnitt zurück, selbst wenn er zu einem anderen Kunden oder einer überholten Vertragsversion gehört. Beheben Sie das schon beim Einlesen der Daten, kostet es wenig. Entdecken Sie das Problem erst, nachdem bereits einige Millionen Vektoren indexiert sind, wird es sehr teuer.
