Vektordatenbanken erklärt: Pinecone, Weaviate & Co.
Sobald eine KI auf Ihre eigenen Dokumente zugreifen soll – Handbücher, Verträge, Support-Tickets – stößt die klassische Datenbank an eine harte Grenze: Sie findet Wörter, nicht Bedeutung. Wer nach „Gerät startet nicht“ sucht, bekommt den Eintrag über „Netzteil defekt“ nicht zu sehen. Vektordatenbanken lösen genau dieses Problem und sind damit der technische Unterbau fast jeder ernsthaften KI-Anwendung im Unternehmen. Dieser Artikel erklärt das Prinzip, vergleicht die wichtigsten Anbieter und sagt, wann Sie keine brauchen.
Warum relationale Datenbanken hier nicht reichen
Eine klassische Suche vergleicht Zeichenketten. Sie findet, was Sie geschrieben haben – und nichts, was dasselbe bedeutet. Volltextsuche mildert das durch Wortstammreduktion und Synonymlisten, aber das Grundproblem bleibt: Sie müssen die Begriffe kennen, die im Dokument stehen.
Für KI-Anwendungen ist das die falsche Suchlogik. Wenn ein Sprachmodell die passenden Stellen aus 5.000 Seiten Dokumentation bekommen soll, muss die Suche nach Bedeutung funktionieren:
Genau das leistet eine Vektorsuche.
Das Funktionsprinzip in drei Schritten
Schritt 1: Embeddings
Ein Embedding-Modell übersetzt einen Textabschnitt in eine Liste von Zahlen – typischerweise 768 bis 3.072 Werte. Dieser Zahlenvektor ist eine Position in einem hochdimensionalen Raum, und die entscheidende Eigenschaft ist: Texte mit ähnlicher Bedeutung landen an nahen Positionen. Das gilt über Formulierungen und Sprachen hinweg, weil das Modell auf Bedeutungsnähe trainiert wurde, nicht auf Wortgleichheit.
Schritt 2: Ähnlichkeit messen
Um zu finden, was zu einer Frage passt, wird die Frage ebenfalls in einen Vektor übersetzt und der nächste Nachbar gesucht. Das gängige Maß ist die Kosinus-Ähnlichkeit: Sie bewertet den Winkel zwischen zwei Vektoren und ignoriert deren Länge – ein kurzer und ein langer Text mit gleicher Aussage gelten damit als ähnlich.
Schritt 3: Schnell werden
Hier kommt die Datenbank ins Spiel. Bei einer Million Dokumenten jeden Vektor einzeln zu vergleichen, ist exakt aber zu langsam. Vektordatenbanken nutzen deshalb approximative Nachbarschaftssuche – Verfahren wie HNSW, das die Vektoren in einem mehrstufigen Graphen organisiert. Das Ergebnis ist nicht garantiert perfekt, sondern typischerweise zu 95 bis 99 Prozent korrekt, dafür aber hundert- bis tausendfach schneller.
Dieser Kompromiss ist der ganze Zweck einer Vektordatenbank. Sie verkauft Ihnen ein wenig Genauigkeit für sehr viel Geschwindigkeit. Der Grad ist einstellbar: Wer mehr Genauigkeit will, akzeptiert längere Antwortzeiten. Dieser Regler ist die wichtigste Einstellung beim Betrieb – und die, die am häufigsten auf dem Standardwert bleibt.
Wo das im RAG-Kontext steht
Der Hauptanwendungsfall heißt Retrieval Augmented Generation: Das Sprachmodell bekommt vor der Antwort die passenden Ausschnitte aus Ihren Daten mitgeliefert. Der Ablauf:
Der häufigste Fehler in RAG-Projekten liegt nicht bei der Datenbank. Er liegt in Schritt eins und vier. Schlecht geschnittene Abschnitte – etwa eine Tabelle, die mitten in einem Abschnitt abbricht – lassen sich durch keine Datenbank retten. Und wer den Reranker auslässt, verschenkt den größten Qualitätssprung im ganzen Aufbau. Die Wahl des Anbieters ist für die Antwortqualität fast immer die unwichtigste Entscheidung. Wie ein solcher Aufbau insgesamt aussieht, zeigt Persönlicher KI-Assistent für Unternehmen.
Ebenso wichtig: Metadatenfilter. Eine reine Bedeutungssuche kennt keine Berechtigungen. Wenn ein Mitarbeiter nur Dokumente seiner Abteilung sehen darf, muss die Suche vor oder während der Ähnlichkeitsbewertung filtern können – und zwar effizient. Dieser Punkt unterscheidet die Anbieter stärker als jeder Geschwindigkeitswert.
Der Anbietervergleich
| System | Art | Lizenz | Stärke | Praktikable Größenordnung |
|---|---|---|---|---|
| pgvector | Postgres-Erweiterung | Open Source | liegt in derselben Datenbank wie Ihre Anwendungsdaten | bis etwa 100 Mio. Vektoren |
| Qdrant | dedizierte Vektor-DB | Apache 2.0 | sehr niedrige Latenz, starkes Filtern auf Metadaten | einige 100 Mio. |
| Weaviate | dedizierte Vektor-DB | BSD-3 | eingebaute Vektorisierung, Hybridsuche, Mandantentrennung | einige 100 Mio. |
| Milvus | dedizierte Vektor-DB | Apache 2.0 | GPU-Beschleunigung, sehr große Bestände | Milliarden |
| Pinecone | nur als Dienst | proprietär | kein Betriebsaufwand, schnellster Start | Milliarden |
| Elasticsearch / OpenSearch | Suchmaschine mit Vektorteil | gemischt | wenn Volltextsuche schon im Einsatz ist | je nach Aufbau |
pgvector: die unterschätzte Standardantwort
Wenn Ihre Anwendung bereits PostgreSQL nutzt – und das tun sehr viele – ist pgvector in der Regel die richtige Wahl für den Anfang. Die Vektoren liegen als Spalte neben Ihren übrigen Daten. Das hat drei Vorteile, die schwer zu überschätzen sind: ein System weniger zu betreiben, Filter und Verknüpfungen in normalem SQL, und Transaktionssicherheit zwischen Dokument und Vektor. Kein Abgleichproblem zwischen zwei Datenbanken, das in jedem zweiten Projekt mit externer Vektordatenbank irgendwann auftritt.
Die Grenzen liegen bei sehr großen Beständen und hoher Abfragelast. Erweiterungen wie pgvectorscale verschieben diese Grenze deutlich nach oben; Benchmarks nennen Hunderte Abfragen pro Sekunde bei 50 Millionen Vektoren mit 99 Prozent Trefferquote. Für den Großteil der Unternehmensanwendungen – oft einige Zehn- bis Hunderttausend Abschnitte – ist das weit jenseits des Bedarfs.
Realitätscheck zur Größenordnung: 10.000 Seiten Dokumentation ergeben grob 30.000 bis 60.000 Abschnitte. Das ist für pgvector eine kleine Tabelle. Die Debatte um Milliarden-Skalierung betrifft die meisten Unternehmensprojekte nicht – sie wird von Anbietern geführt, deren Produkt sich darüber unterscheidet.
Qdrant: wenn Filter und Latenz zählen
Qdrant ist in Rust geschrieben, vollständig Apache-2.0-lizenziert und in Messungen regelmäßig an der Spitze bei Antwortzeiten. Die eigentliche Stärke ist das Filtern: Bedeutungssuche mit gleichzeitiger Einschränkung auf Metadaten ist technisch anspruchsvoll, weil Filter die Struktur des Suchgraphen zerstören können. Qdrant hat dafür eigene Verfahren und löst den Fall sauber. Es gibt eine dauerhaft kostenlose Cloud-Stufe und einen klaren Pfad zum Selbstbetrieb – für Projekte mit Datenschutzanforderungen die angenehmste Kombination.
Weaviate: Hybridsuche und Mandanten
Weaviate bringt Vektorisierung als Modul mit: Dokumente gehen als Text hinein, das Einbetten übernimmt die Datenbank. Das verkürzt den Einstieg, erzeugt aber eine Abhängigkeit mehr. Gute Hybridsuche – Bedeutung und Schlagwort kombiniert – und ausgereifte Mandantentrennung machen es zur passenden Wahl, wenn Sie eine Anwendung für mehrere Kunden betreiben und Daten hart trennen müssen.
Milvus: für den Fall, dass es sehr groß wird
Milvus ist auf Milliarden Vektoren und GPU-Beschleunigung ausgelegt und entsprechend aufwendig zu betreiben – die verteilte Architektur bringt mehrere Komponenten mit. Für kleine Bestände ist es überdimensioniert. Als verwalteter Dienst ist es über Zilliz Cloud verfügbar.
Pinecone: der Dienst ohne Betrieb
Pinecone war der erste bekannte Anbieter und ist nach wie vor der schnellste Weg zu einem funktionierenden Ergebnis: Konto anlegen, Index erzeugen, Vektoren hochladen – kein Server, keine Wartung. Der Preis dafür: kein Selbstbetrieb möglich, alle Daten liegen beim Anbieter, und die Kosten wachsen mit dem Bestand. Für Projekte mit strengen Anforderungen an Datenhaltung und Serverstandort ist das ein Ausschlusskriterium, für einen schnellen Machbarkeitsnachweis eine sehr gute Wahl.
Auswahlkriterien, die wirklich entscheiden
Geschwindigkeit steht in jedem Vergleich oben und ist in der Praxis selten der Engpass – ein Sprachmodell braucht für seine Antwort typischerweise eine bis mehrere Sekunden, da fallen 20 Millisekunden Unterschied bei der Suche nicht auf. Diese Kriterien sind wichtiger:
Kosten realistisch einschätzen
Die Preisangaben in Vergleichen schwanken stark, weil unterschiedliche Vektorgrößen, Abfragelasten und Verfügbarkeitsstufen gerechnet werden. Als Orientierung für etwa 10 Millionen Vektoren nennen aktuelle Auswertungen Beträge im Bereich von 45 bis 135 US-Dollar monatlich, je nach Anbieter; bei 100 Millionen Vektoren öffnet sich die Schere deutlich – verwaltete Dienste können dreistellig bis vierstellig werden, während selbst betriebene Systeme auf Serverkosten im unteren dreistelligen Bereich bleiben.
Was in diesen Rechnungen fehlt: Beim Selbstbetrieb die Arbeitszeit. Realistische Schätzungen setzen für Betrieb und Bereitschaft eines zusätzlichen Datenbanksystems einen Gegenwert von einigen hundert Euro pro Monat an. Der Umschlagpunkt liegt damit höher, als die reinen Infrastrukturkosten suggerieren: Unterhalb einer verwalteten Rechnung von etwa 300 Euro monatlich ist der Dienst meist günstiger als der Eigenbetrieb – es sei denn, Sie betreiben die Datenbank ohnehin schon, und genau das ist das Argument für pgvector.
Die dritte Kostenposition, die oft überrascht: das Einbetten selbst. Jedes Dokument muss einmal durch ein Embedding-Modell, jede Suchanfrage ebenfalls. Bei großen Erstbeständen ist das ein einmaliger Posten, der sich rechnen lässt; bei hoher Abfragelast wird es ein laufender. Wie sich solche Nutzungskosten bei KI-Schnittstellen generell verhalten, behandelt KI-APIs integrieren.
Wann Sie keine Vektordatenbank brauchen
Diese Fälle sind häufiger als gedacht:
Fazit
Vektordatenbanken lösen ein konkretes Problem: Suche nach Bedeutung statt nach Wortgleichheit. Das Prinzip ist in zwei Sätzen erklärt – Texte werden zu Positionen in einem Raum, Ähnlichkeit ist Nähe – und der Rest ist Betriebsentscheidung. Die pragmatische Reihenfolge: Für den Machbarkeitsnachweis eine einfache Bibliothek ohne eigene Datenbank. Für die erste produktive Anwendung pgvector, wenn Sie Postgres schon betreiben, sonst Qdrant. Pinecone, wenn es schnell gehen muss und die Daten beim Anbieter liegen dürfen; Milvus, wenn es wirklich sehr groß wird. Und wichtiger als jede Anbieterentscheidung: ordentlich geschnittene Abschnitte, Metadaten für Filter und ein Reranker. Daran entscheidet sich die Qualität, nicht am Produktnamen.