Wenn ein Knowledge Hub gebaut wird, steht früh die Frage nach der Vector-DB. Die ehrliche Antwort für die meisten KMU-Projekte: pgvector reicht. Nicht immer, aber häufiger als die Marketing-Folien spezialisierter Anbieter vermuten lassen.
Was pgvector heute kann
- ANN-Suche per HNSW oder IVFFlat, ausreichend schnell für Hunderttausende Embeddings.
- Filter über klassische SQL-Spalten kombinierbar – Mandanten, Rollen, Zeitfenster.
- Backup, Replikation und Monitoring identisch zu jedem anderen Postgres-Cluster.
- Keine zweite Infrastruktur zu betreiben, keine zusätzliche Auth-Schicht.
Wann eine spezialisierte Vector-DB lohnt
Sobald Latenzbudgets unter 50 ms pro Query liegen, Hunderte Millionen Vektoren im Spiel sind oder hybride Suche mit feingranularen Re-Ranking-Strategien nötig wird, gewinnt eine dedizierte Lösung. Auch dann gilt: erst bauen, wenn der Bedarf belegt ist – nicht prophylaktisch.
Migration: pgvector → Qdrant
Wenn der Wechsel ansteht, ist die Migration meistens unspektakulär: Embeddings werden batchweise exportiert, in das Zielsystem geladen, der Index wird neu aufgebaut. Wichtig ist die Mapping-Tabelle (Vector-ID → Source-Document) und ein paralleler Cutover, damit keine Anfrage verloren geht.
Worauf es wirklich ankommt
- Sauberes Chunking: lieber semantisch geschnitten als mechanisch nach Tokens.
- Embedding-Modell mit klarer Versionierung – Änderungen erfordern Re-Indexing.
- Quellenverweise in jeder Antwort – ohne sie ist RAG nicht prüfbar.
- Eval-Set mit echten Fragen, regelmäßig nachgeschärft.
