Ein Unternehmen mit 500.000 Dokumentenfragmenten und bestehendem PostgreSQL steht vor der Frage, die wir uns regelmäßig stellen: Soll man einfach pgvector hinzufügen und das Thema in zwei Tagen abschließen, oder direkt Qdrant aufsetzen? Die Antwort hängt von mehreren Kriterien ab, die selten in einem Artikel zusammengeführt werden. Im Folgenden haben wir sie an einem Ort zusammengefasst.
Worin unterscheiden sich pgvector und eine dedizierte Vektordatenbank
#pgvector ist eine PostgreSQL-Erweiterung, die den Datentyp vector und Ähnlichkeitsoperatoren (L2, Cosinus, Skalarprodukt) hinzufügt. Die Vektoren befinden sich in derselben Datenbank wie die restlichen Transaktionsdaten (zusammen mit Tabellen für Kunden, Bestellungen und Dokumente). Das ist ein großer operativer Vorteil: ein Backup, eine Berechtigungsverwaltung, ein Monitoring.
Eine dedizierte Vektordatenbank (Qdrant, Weaviate, Milvus) ist ein separater Prozess, der ausschließlich für die Speicherung und Suche von Vektoren entwickelt wurde. Ihr Indexierungsmotor (meist HNSW) ist für approximative Nachbarschaftssuche (ANN) mit sehr geringer Latenz optimiert, selbst bei zig Millionen Vektoren.
Der Unterschied ist nicht binär; es ist ein Spektrum von Kompromissen. Seit Version 0.7.0 unterstützt pgvector den HNSW-Index (zuvor nur IVFFlat), was die Leistungslücke deutlich verkleinert hat. Bei 100–200.000 Vektoren und einigen Abfragen pro Sekunde ist diese Lücke heute vernachlässigbar.
Fünf Kriterien, die wirklich entscheiden
#Skalierung des Korpus. pgvector mit HNSW-Index hält sich gut bis etwa 1–2 Mio. Vektoren auf einem durchschnittlichen Server (16 GB RAM, 8 Kerne). Oberhalb dieser Schwelle beginnen der Indexaufbau und der Speicherverbrauch mit anderen Workloads der Datenbank zu konkurrieren. Qdrant verwaltet den Speicher pro Collection und kann einen Teil des Index auf der Festplatte halten (mmap), was die Skalierung auf hunderte Millionen Vektoren ohne Serverwechsel ermöglicht.
Metadatenfilterung (Payload Filtering). Hier scheitert pgvector in der Praxis am häufigsten. Die Filterung WHERE category = 'hr' AND status = 'active' vor der Vektorsuche in pgvector ist in Wirklichkeit ein Post-ANN-Filter oder ein vollständiger Scan mit Pre-ANN-Filter. Beide sind kostspielig. Qdrant baut invertierte Indizes auf Payload-Feldern auf und kombiniert sie mit dem HNSW-Pfad, sodass must: [{ key: "category", match: { value: "hr" } }] die Abfrage nicht verlangsamt. Wenn dein RAG Fragmente nach Abteilung, Kunde oder Zugriffsebene isolieren muss, ist Payload-Filtering ein kritisches Kriterium.
Hybride Abfragen (Vektor + Volltext). pgvector hat kein integriertes BM25; man muss es mit tsvector von PostgreSQL kombinieren und die Ergebnisse manuell zusammenführen (RRF oder eigene Logik). Qdrant unterstützt seit Version 1.10 native hybride Suche mit Reranking in einem einzigen API-Aufruf. Für Systeme, in denen Nutzer sowohl natürliche Fragen als auch Dokumentennummern oder Codes eingeben, ist die Hybridlösung wichtig. Details beschreiben wir im Artikel über hybride Suche mit BM25 und Vektoren.
Self-Hosting vs. SaaS und DSGVO-Anforderungen. Beide Optionen lassen sich auf dem eigenen Server betreiben. pgvector ist Teil von PostgreSQL, sodass bei bestehender On-Prem-Datenbank und Retentionsrichtlinie das Hinzufügen der Erweiterung das Bedrohungsmodell nicht verändert. Qdrant Cloud (SaaS) erfordert einen Auftragsverarbeitungsvertrag (Art. 28 DSGVO) und eine DPO-Bewertung hinsichtlich Data-Residency. Embedding-Daten sind keine PII, aber wenn der Payload Kundendaten enthält, ist die Speicherregion relevant. Qdrant Community Edition on-premises hat genau dasselbe DSGVO-Profil wie pgvector auf dem eigenen Server. Mehr zur DSGVO-konformen Infrastruktur im Artikel über Self-Hosted LLM und DSGVO.
Operative Komplexität und TCO. pgvector fügt dem Stack keine neuen Komponenten hinzu: ein Service, ein Backup, ein Team. Qdrant ist ein separater Dienst (Container oder Prozess) mit eigenen Metriken und Updates. In kleinen Teams ohne DevOps ist das ein realer Unterschied: nicht nur Lizenzkosten, sondern auch Wartungsaufwand. Andererseits bietet Qdrant fertige Prometheus-Endpoints und Collection-Dashboards, was die Observability bei großen Volumina vereinfacht.
Tabelle: pgvector vs. dedizierte Vektordatenbank
#| Kriterium | pgvector | Dedizierte Datenbank (z. B. Qdrant) |
|---|---|---|
| Skalierung bis 1–2 Mio. Vektoren | gut (HNSW 0.7+) | gut |
| Skalierung über 2 Mio. Vektoren | begrenzt (RAM/Build-Time) | gut (mmap, Disk-Segmente) |
| Payload-Filterung | Post-ANN oder Scan | nativ (Pre-ANN) |
| Hybride Suche | manuelle Komposition (tsvector+RRF) | nativ (ab Qdrant 1.10) |
| Neue Infrastrukturkomponenten | keine (PostgreSQL-Erweiterung) | separater Service |
| Self-Hosting DSGVO | ja (wie ganz PostgreSQL) | ja (Community Edition) |
| SaaS (Cloud) | ja (z. B. Supabase, Neon) | ja (Qdrant Cloud, Pinecone) |
| Backup und Migrationen | gemeinsam mit PostgreSQL | separat (Snapshots API) |
| Multi-Tenant-Isolation | Schemas / RLS | Collections pro Tenant |
| Typische Startkosten | 0 (PostgreSQL bereits vorhanden) | Implementierungszeit ~1–3 Tage |
Wann pgvector die richtige Wahl ist
#pgvector macht Sinn, wenn du bereits PostgreSQL im Unternehmen nutzt, dein Korpus zwischen 500.000 und 1 Mio. Fragmente umfasst, die Abfragen einfach sind (ohne komplexes Payload-Filtering) und du keine neue Komponente zur Infrastruktur hinzufügen möchtest. Die Implementierung reduziert sich auf CREATE EXTENSION vector, das Hinzufügen einer Spalte und das Erstellen eines HNSW-Index. Das Team kann dies an einem Tag umsetzen. Bei diesem Umfang liegt die Abfragelatenz bei 20–80 ms, was für die meisten internen Wissensassistenten absolut ausreichend ist.
pgvector ist auch die natürliche Wahl für semantische Suche, wenn personenbezogene Daten die Transaktionsdatenbank nicht verlassen dürfen: Embeddings und Payload bleiben im selben Engine mit demselben Berechtigungsmodell.
Wann der Wechsel zu einer dedizierten Datenbank sinnvoll ist
#Anzeichen, dass es Zeit für Qdrant oder eine andere dedizierte Datenbank ist:
- Der Korpus überschreitet 2 Mio. Fragmente und die Build-Time des HNSW-Index in pgvector überschreitet das Wartungsfenster.
- Du benötigst Payload-Filterung vor der ANN-Suche, z. B. Kundenisolation in einem Multi-Tenant-System, Filter nach Dokumentenstatus oder Zugriffsebene.
- Du implementierst hybride Suche (Vektor + BM25) und möchtest keine separate Logik zur Ergebniszusammenführung pflegen.
- Du möchtest Collections pro Produkt oder Kunde isolieren, ohne die Performance anderer Collections zu beeinträchtigen.
- Du planst viele gleichzeitige Schreiboperationen (inkrementelle Reindexierung stündlich) und möchtest die Haupt-Transaktionsdatenbank nicht belasten.
Bei der Skalierung über 5–10 Mio. Fragmente ist eine dedizierte Datenbank praktisch die einzige sinnvolle Option. Wir beschreiben dies ausführlicher im Artikel über die Vorbereitung von Unternehmensdaten für AI.
Migrationsmuster: von pgvector zu Qdrant
#Wenn ihr mit pgvector beginnt und nach einigen Monaten über die Schwelle wachst, ist die Migration einfacher als gedacht. Vektoren sind Gleitkommazahlen. Der Export aus pgvector ins JSON-Format und der Reimport in Qdrant sind eine Frage eines einzigen ETL-Skripts. Das Payload-Schema wird einmal gemappt. Der gesamte Prozess für 2 Mio. Vektoren dauert 2–4 Stunden. Das Dual-Index-Muster (alter pgvector + neuer Qdrant laufen parallel, Traffic wird schrittweise migriert) minimiert das Risiko, ähnlich wie bei der Migration von API zu eigenem AI-Modell.
Ausprobieren: Stack nach Anforderungen auswählen
#FAQ
#Eignet sich pgvector für produktives RAG?
#Ja, bei Datensätzen bis 1–2 Mio. Fragmente und HNSW-Index (pgvector 0.7+) ist dies eine voll produktionsreife Lösung. Viele Unternehmen implementieren RAG genau mit pgvector, da keine neue Infrastrukturkomponente benötigt wird. Einschränkungen treten bei fortgeschrittenem Payload-Filtering und großer Skalierung auf; in diesen Fällen lohnt sich die Evaluierung von Qdrant.
Wie unterscheiden sich die Latenzen zwischen pgvector und Qdrant bei großen Datensätzen?
#Bei 500.000 Vektoren ist der Unterschied vernachlässigbar (beide liegen bei 20–60 ms auf einem typischen Server). Bei 5 Mio. Vektoren hält Qdrant mit Disk-Segmenten (mmap) 30–80 ms, während pgvector bei unzureichendem RAM in den Bereich von 200–500 ms kommen kann. Dies hängt stark von der Serverkonfiguration und den Parametern ef_construction / m des HNSW-Index ab.
Ist Qdrant Community Edition DSGVO-konform?
#Ja, Qdrant Community Edition on-premises hat dasselbe DSGVO-Profil wie pgvector auf dem eigenen Server: Daten verlassen die Infrastruktur nicht, es gibt keine Rücktelemetrie zum Hersteller (in der Standardkonfiguration). Qdrant Cloud (SaaS) erfordert eine separate Bewertung der Data-Residency und einen Auftragsverarbeitungsvertrag. Entscheidend ist, dass im Payload der Collection keine unverschlüsselten personenbezogenen Daten enthalten sein sollten, unabhängig von der gewählten Datenbank.
Wie viel kostet die Implementierung von Qdrant in einem Unternehmen?
#Qdrant Community Edition ist Open-Source-Software ohne Lizenzgebühren. Die Implementierungskosten umfassen die Zeit des Teams (1–3 Tage für Konfiguration, API-Integration und Tests), den Server (bei 2 Mio. Vektoren BGE-M3 1024-dim werden ca. 8–12 GB RAM für den HNSW-Index benötigt) und den Wartungsaufwand. Bei Collections über 10 Mio. Vektoren lohnt sich die Betrachtung von Qdrant Cloud oder einer dedizierten Maschine. Einen Rechner für die Gesamtkosten der Implementierung findest du im ROI-Kalkulator.
Kann man pgvector und Qdrant gleichzeitig nutzen?
#Ja, und das macht in einer Architektur Sinn, in der Transaktionsdaten (kurze Beschreibungen, Metadaten) in pgvector liegen und große Dokumenten-Collections in Qdrant. Das Dual-Index-Muster ist auch bei Migrationen nützlich: Neue Fragmente gehen in Qdrant, alte bleiben in pgvector bis zum vollständigen Reimport. Beide Systeme können parallel abgefragt und die Ergebnisse durch Reranking zusammengeführt werden.