Vektordatenbank im Unternehmen: wann sie sich lohnt und wann pgvector reicht

Jedes KI-Projekt, das interne Dokumente durchsuchbar machen soll, stößt auf dieselbe Frage: Wohin mit den Embeddings? Der Reflex ist eine dedizierte Vektordatenbank, und manchmal ist das richtig. Oft ist es verfrüht, und im DACH-Raum kommt eine zweite Frage hinzu, die viele übersehen: Wo dürfen diese Daten überhaupt liegen? Dieser Artikel erklärt, was eine Vektordatenbank leistet, wann sie sich lohnt und warum Souveränität mitentscheidet.

Was eine Vektordatenbank leistet

Eine Vektordatenbank speichert hochdimensionale Vektoren, sogenannte Embeddings, und beantwortet eine Frage schnell: Welche gespeicherten Vektoren liegen einem Suchvektor am nächsten? Nähe im Vektorraum entspricht semantischer Ähnlichkeit. Damit wird aus "finde die ähnlichsten Vektoren" ein "finde die relevantesten Textpassagen zu dieser Frage". Das ist der Retrieval-Schritt hinter semantischer Suche, Empfehlungen und Retrieval-Augmented Generation (RAG).

Exakte Suche über Millionen Vektoren wäre zu langsam, deshalb nutzen Vektordatenbanken Approximate-Nearest-Neighbor-Suche (ANN). Der verbreitete Index ist HNSW (Hierarchical Navigable Small World): ein Graph, der einen kleinen, einstellbaren Verlust an Trefferquote gegen einen großen Geschwindigkeitsgewinn tauscht. Ebenso wichtig ist, dass eine Vektordatenbank Metadaten mitspeichert und danach filtert, etwa nach Mandant, Datum oder Zugriffsstufe. In Unternehmen ist diese Filterung oft entscheidender als die reine Suchgeschwindigkeit.

Wann pgvector genügt

Der häufigste Fehler ist, zu einer spezialisierten Vektordatenbank zu greifen, bevor das Problem es verlangt. Für einen großen Teil der Projekte ist die pragmatische Antwort pgvector: eine Erweiterung, die Vektorspalten und ANN-Indizes zu einem ohnehin vorhandenen PostgreSQL hinzufügt.

pgvector bewältigt Millionen Vektoren, unterstützt HNSW-Indizierung und hält alles in einem System. Das bedeutet eine Backup-Strategie, ein Zugriffsmodell, eine Betriebsoberfläche. Die Metadaten, nach denen gefiltert wird, liegen meist ohnehin in relationalen Tabellen, sodass ein Join den systemübergreifenden Zugriff ersetzt. Für Bestände im Bereich von zehntausenden bis wenigen hunderttausend Dokumenten ist das kein Kompromiss, sondern die richtige Architektur, und sie verschiebt die Entscheidung für eine dedizierte Engine auf den Zeitpunkt, an dem echte Nutzungsdaten sie rechtfertigen.

Wann eine dedizierte Engine sich lohnt

Eine dedizierte Vektordatenbank (Qdrant, Weaviate, Milvus oder gehostete Dienste) rechtfertigt sich, wenn konkrete Anforderungen auftreten:

• Größe: Bestände im zweistelligen Millionenbereich und darüber, wo der Vektorindex einer Allzweckdatenbank an Grenzen stößt.
• Durchsatz und Latenz: hohe Abfragelast bei engem Latenzbudget, wo spezialisierte Indizierung und Caching zählen.
• Gefilterte und hybride Suche im großen Maßstab: Vektorähnlichkeit kombiniert mit Metadatenfiltern und Schlüsselwortsuche (BM25), effizient über große Sammlungen.
• Horizontale Skalierung: Sharding und Replikation, die für Vektorlasten ausgelegt sind statt nachträglich aufgesetzt.

Die Entscheidung sollte Belegen folgen, nicht dem Trend. Eine verteilte Vektordatenbank für hunderttausend Dokumente fügt ein System hinzu, das betrieben, gesichert und abgesichert werden will, im Tausch gegen Reserven, die niemand nutzt.

Souveränität: wo die Embeddings liegen

Für Unternehmen im DACH-Raum ist die Retrieval-Schicht auch eine Frage der Datenresidenz. Embeddings werden aus Quelldokumenten abgeleitet und können je nach Inhalt selbst personenbezogene oder sensible Daten sein. Sie an einen gehosteten Vektordienst außerhalb der EU zu senden oder über eine externe API zu erzeugen, verschiebt diese Daten über eine Grenze, die DSGVO und interne Richtlinien möglicherweise nicht zulassen.

Genau deshalb sind selbst hostbare Engines (Qdrant, Weaviate, Milvus) und die In-Datenbank-Variante pgvector mehr als eine Kostenfrage. Sie halten sowohl die Embeddings als auch das Retrieval in einer kontrollierten, europäischen Umgebung. Das ist dieselbe Logik, die selbst gehostete Sprachmodelle antreibt: Die sensiblen Daten bleiben dort, wo das Unternehmen die Kontrolle hat. Retrieval-Schicht und Modell-Schicht teilen dieselbe Anforderung.

Warum die meisten Retrieval-Probleme nicht die Datenbank sind

Wenn ein RAG-System falsche Antworten liefert, ist selten die Datenbank die Ursache. Die Qualität des Retrievals entscheidet sich davor, und ein schneller Index über schlechten Eingaben liefert schlechte Ergebnisse nur schneller.

• Chunking: Wie Dokumente zerteilt werden, bestimmt, was überhaupt gefunden werden kann. Zu große Chunks verwässern die Relevanz, zu kleine verlieren den Kontext.
• Embedding-Modell: Es legt fest, was "ähnlich" bedeutet. Ein für die Domäne oder für Deutsch schlecht passendes Modell erzeugt einen Raum, in dem die falschen Dinge nah beieinander liegen.
• Metadatenfilterung: Ohne Filter nach Zugriffsstufe kann die Suche Dokumente zeigen, die ein Nutzer nicht sehen darf, ein Sicherheitsproblem, kein Relevanzproblem.
• Evaluation: Ohne Testset aus Frage-Antwort-Paaren lässt sich nicht sagen, ob eine Änderung geholfen hat.

Die Reihenfolge der Investition ist damit klar: erst Chunking, Embeddings, Filterung und Evaluation auf der einfachsten funktionierenden Speicherung, dann die Datenbank nach der tatsächlich erreichten Größe wählen.

Typische Fehler

Aus der Praxis: die Muster, die Vektor-Retrieval schwächen.

1. Dedizierte Datenbank zuerst. Eine verteilte Engine für einen Bestand, den pgvector bewältigt hätte.

2. Kein Evaluationsset. Retrieval ohne Messmöglichkeit, sodass jede Änderung ein Ratespiel bleibt.

3. Chunking als Nachgedanke. Naiv zerteilte Dokumente, die die Antwortqualität deckeln.

4. Embeddings über eine Grenze. Sensible Inhalte über eine externe API oder in einem Nicht-EU-Dienst, mit Residenzproblem.

5. Keine Metadatenfilterung. Ähnlichkeitssuche ohne Zugriffsfilter, die Dokumente an Unbefugte ausliefert.

Retrieval-Architektur besprechen

DNA Solutions unterstützt Unternehmen im DACH-Raum beim Aufbau der Retrieval-Schicht hinter semantischer Suche und RAG: die passende Speicherung für die tatsächliche Größe, selbst gehostet und EU-resident, wo Souveränität es verlangt, mit Chunking, Embeddings, Filterung und Evaluation als den Teilen, die über Qualität entscheiden. Ob Sie mit pgvector starten oder unter Last auf eine dedizierte Engine skalieren, wir dimensionieren es am Problem statt am Hype. Sprechen Sie uns an.