EnglishAI-Designers
Wer KI über die eigenen Dokumente laufen lässt, stößt früher oder später auf eine unscheinbare Komponente, die über Erfolg oder Frust entscheidet: die Vektordatenbank. Sie speichert die Zahlenrepräsentationen Ihrer Texte, Bilder und Tabellen und findet in Millisekunden die passenden Treffer zu einer Frage. Lange galt sie als Nischenthema für Forschungsteams. Heute betreiben Fachabteilungen sie produktiv – und viele wollen sie nicht in einer fremden Cloud wissen, sondern im eigenen Rechenzentrum.
Der Grund ist selten Technik-Romantik. Es geht um Kontrolle über sensible Daten, um planbare Kosten und um die Freiheit, nicht an einem Anbieter zu kleben. Dieser Beitrag zeigt, wann sich das Selbst-Hosten lohnt, welche drei Systeme sich dafür durchgesetzt haben und worauf Sie im Betrieb achten sollten.
Warum die Vektordatenbank so viel Gewicht bekommt
Ein Sprachmodell weiß nur, was in seinem Training steckte. Ihr Vertragsarchiv, die Wartungsprotokolle der letzten Jahre, die internen Richtlinien – all das kennt es nicht. Retrieval-Augmented Generation schließt diese Lücke: Das System durchsucht Ihre Datenbestände, reicht die relevanten Passagen an das Modell weiter und lässt daraus eine Antwort formulieren. Die Vektordatenbank ist dabei das Nachschlagewerk, das in Sekundenbruchteilen entscheidet, welche Passagen überhaupt gezeigt werden.
Taugt dieser Schritt nichts, hilft auch das beste Modell nicht mehr. Findet die Datenbank die falschen Absätze, erfindet das Modell freundlich klingenden Unsinn. Deshalb verdient die Suchschicht die gleiche Aufmerksamkeit wie das Modell selbst – oft mehr, weil hier die meisten Qualitätsprobleme entstehen.
Hinzu kommt der Datenschutz. Wer medizinische Befunde, Personalakten oder Konstruktionsdaten einbettet, schickt deren inhaltliche Essenz in die Datenbank. Liegt die bei einem US-Anbieter, verlässt dieses Destillat Ihrer Geschäftsgeheimnisse das Haus. Genau deshalb wächst das Interesse am eigenen Betrieb.
Wann sich der eigene Betrieb rechnet
Nicht jedes Projekt braucht eine selbst gehostete Datenbank. Ein kleiner Prototyp mit ein paar tausend Dokumenten läuft problemlos auf einem Managed-Dienst, und das spart anfangs Nerven. Die Rechnung dreht sich, sobald drei Dinge zusammenkommen: viele Millionen Vektoren, strenge Vorgaben zum Datenstandort und ein Team, das die Pipeline ohnehin dauerhaft betreut.
Dann zahlt sich Kontrolle aus. Sie bestimmen, auf welcher Hardware die Suche läuft, wie oft neu indexiert wird und wer Zugriff bekommt. Die Kosten koppeln sich von der Zahl der Abfragen ab und hängen stattdessen an Ihrer Infrastruktur – ein Vorteil, sobald die Last steigt. Und Sie bleiben beweglich: Kein Anbieter kann Ihnen über Nacht die Preise verdoppeln oder eine Funktion streichen, auf die Sie gebaut haben.
Drei Systeme, die sich durchgesetzt haben
pgvector ist die pragmatischste Wahl. Es erweitert die vertraute PostgreSQL-Datenbank um Vektorsuche. Wer Postgres ohnehin betreibt, bekommt Ähnlichkeitssuche ohne ein weiteres System im Stack – inklusive Transaktionen, Backups und Rechteverwaltung, die das Betriebsteam längst beherrscht. Für Bestände bis in den zweistelligen Millionenbereich reicht das in vielen Fällen vollkommen.
Qdrant ist von Grund auf für Vektoren gebaut. Es glänzt beim Filtern: Sie suchen nicht nur nach inhaltlicher Nähe, sondern grenzen gleichzeitig nach Abteilung, Dokumenttyp oder Datum ein – und das bleibt auch bei großen Beständen schnell. Die Rechteverwaltung über solche Filter macht Qdrant attraktiv, wenn verschiedene Nutzergruppen nur Teile des Archivs sehen dürfen.
Milvus zielt auf die ganz großen Mengen. Es trennt Speicherung, Indexierung und Abfrage in eigene Dienste, die Sie getrennt skalieren. Das bringt Betriebsaufwand mit sich, zahlt sich aber aus, sobald Sie Milliarden Vektoren über viele Maschinen verteilen. Für ein Team, das gerade erst startet, ist Milvus meist zu schwer – für eine konzernweite Suche über alle Standorte oft genau richtig.
HNSW, Quantisierung und der Preis der Geschwindigkeit
Alle drei Systeme setzen auf denselben Trick, um schnell zu bleiben: Sie durchsuchen nicht jeden Vektor einzeln, sondern bauen einen Index, der die Suche abkürzt. Das verbreitetste Verfahren heißt HNSW – ein mehrschichtiges Netz von Verbindungen, das Abfragen in Sekundenbruchteilen zum passenden Nachbarn führt. Der Haken: Der Index frisst Arbeitsspeicher, und zwar oft mehr als die rohen Daten selbst.
Hier kommt Quantisierung ins Spiel. Statt jede Zahl in voller Genauigkeit zu halten, speichert das System sie grob gerundet – bei binärer Quantisierung sogar nur als ein Bit pro Dimension. Der Speicherbedarf schrumpft dramatisch, die Suche wird günstiger, und ein nachgelagerter Prüfschritt fängt den kleinen Genauigkeitsverlust meist wieder ein. Für große Bestände ist das der Hebel, der teure Hardware überflüssig macht.
Die Kunst liegt in der Abwägung. Ein feiner Index liefert präzise Treffer, kostet aber Speicher und Rechenzeit beim Aufbau. Ein grober Index ist billig, übersieht aber gelegentlich den besten Treffer. Diese Stellschrauben gehören getestet, nicht geraten – mit Ihren echten Daten und echten Fragen, nicht mit einem Standard-Benchmark.
Betrieb: Woran Projekte scheitern
Die erste Hürde ist selten die Technik, sondern die Aktualität. Dokumente ändern sich, kommen hinzu, verschwinden. Wer die Datenbank einmal befüllt und dann vergisst, liefert nach einem halben Jahr veraltete Antworten. Planen Sie von Anfang an, wie neue Inhalte eingebettet und alte entfernt werden – automatisiert, nicht per Hand.
Die zweite Hürde ist die Rechteverwaltung. In einem Unternehmen darf nicht jeder alles sehen. Ihre Vektorsuche muss denselben Berechtigungen folgen wie Ihre übrigen Systeme, sonst liefert der KI-Assistent einem Praktikanten plötzlich Vorstandsprotokolle. Lösen Sie das über Filter direkt in der Datenbank, nicht erst in der Anwendung darüber.
Die dritte Hürde ist Beobachtbarkeit. Sie wollen wissen, wie schnell Abfragen laufen, wann der Speicher knapp wird und ob die Trefferqualität abdriftet. Ohne Messwerte tappen Sie im Dunkeln und merken Probleme erst, wenn sich Nutzer beschweren. Ein paar Kennzahlen und Protokolle von Beginn an ersparen später lange Fehlersuche.
Ein pragmatischer Einstieg
Fangen Sie klein an, aber nicht naiv. Starten Sie mit pgvector, wenn Sie Postgres schon haben und Ihre Datenmenge überschaubar ist – das verschafft Ihnen echte Erfahrung, ohne ein neues System einzuführen. Wächst der Bestand oder wird das Filtern wichtig, wechseln Sie zu Qdrant. Erst wenn Sie an die Grenzen einer einzelnen Maschine stoßen, lohnt der Sprung zu Milvus.
Wichtig ist, dass Sie die Einbettungen entkoppelt halten: Welches Embedding-Modell Sie nutzen und welche Datenbank sie speichert, sind zwei getrennte Entscheidungen. So können Sie das eine austauschen, ohne das andere neu aufzubauen. Diese Trennung spart Ihnen bei der ersten größeren Umstellung Wochen Arbeit.
Am Ende ist die selbst gehostete Vektordatenbank kein Selbstzweck, sondern ein Mittel zur Souveränität. Sie behalten Ihre Daten, Ihre Kosten und Ihre Geschwindigkeit in der eigenen Hand – und genau das macht aus einem Experiment eine Lösung, auf die sich Fachabteilungen verlassen.
Sie möchten eine solche Suchschicht sauber aufsetzen oder eine bestehende RAG-Pipeline auf eigene Infrastruktur holen? Die Spezialisten von AI-Designers begleiten Sie von der Modellauswahl über die Vektordatenbank bis zum stabilen Produktivbetrieb – datenschutzkonform und auf Ihre Prozesse zugeschnitten.
Bilder: AI-Designed