Soll man seine Embedding-Vektoren mit der Erweiterung pgvector in einer PostgreSQL-Datenbank speichern oder diese Aufgabe einer dedizierten Vektor-Datenbank anvertrauen? Ein technischer Leitfaden will die Frage eher mit Leistungsmessungen als mit Prinzipienargumenten beantworten, indem er pgvector mit Qdrant vergleicht.
Zwei Architekturen, ein gemeinsames Ziel
pgvector ist eine Open-Source-Erweiterung für PostgreSQL, in Version 0.8.6, die mit PostgreSQL 13 und späteren Versionen kompatibel ist, laut ihrem offiziellen GitHub-Repository. Sie fügt der Datenbank einen speziellen Spaltentyp für Vektoren sowie exakte und approximative Nearest-Neighbor-Suchen hinzu. Konkret kann ein embedding, also die numerische Darstellung eines Inhalts als Vektor, in derselben Tabelle wie die zugehörigen Daten gespeichert und mit der üblichen SQL-Sprache abgefragt werden. Fünf Distanzfunktionen werden angeboten, darunter Kosinus und Skalarprodukt.
Eine dedizierte Vektor-Datenbank ist hingegen ein separater Dienst mit eigener Speicher-Engine, der um die Vektorsuche herum konzipiert ist. Der Leitfaden nennt insbesondere Pinecone, Qdrant, Weaviate, Milvus und ChromaDB. Diese Architekturentscheidung bedeutet, ein zusätzliches System zu deployen, zu überwachen und zu sichern und es mit der Datenbank, die die Referenzdaten enthält, synchron zu halten.
Messungen lokal, dann im großen Maßstab
Der Leitfaden bietet einen reproduzierbaren Test auf einem Laptop an, mit Docker, Python 3.10 oder höher und etwa 8 GB freiem RAM. Der Datensatz ist synthetisch: 100.000 Vektoren mit 1536 Dimensionen, der Größe eines gängigen Embedding-Modells, geladen in beide Systeme mit denselben HNSW-Index-Parametern. Auf solcher Hardware liegen die Latenzen laut Autor zwischen wenigen Millisekunden und einigen Dutzend Millisekunden, mit starken Schwankungen je nach verfügbarer CPU und Speicher. Dieses Volumen bleibt zu bescheiden, um eine Produktionsentscheidung abzuleiten.
Für diese Frage stützt sich der Leitfaden auf eine von Tiger Data veröffentlichte Studie. Sie behandelt 50 Millionen Cohere-Embeddings mit 768 Dimensionen, getestet auf AWS r6id.4xlarge-Maschinen (16 vCPU, 128 GB RAM), mit einer modifizierten Version des ANN-Benchmarks-Tools. Der Leitfaden hebt einen wichtigen Punkt hervor: Der Test wurde mit pgvector in Verbindung mit pgvectorscale durchgeführt, einer Timescale-Erweiterung, die einen anderen Index-Typ, StreamingDiskANN, hinzufügt, und nicht mit pgvector allein.
Laut diesen Ergebnissen erreicht PostgreSQL mit pgvectorscale bei einem Recall von 99 % 471,57 Anfragen pro Sekunde, gegenüber 41,47 für Qdrant. Die mediane Latenz ist fast identisch, mit 31,07 ms gegenüber 30,75 ms. Qdrant zeichnet sich hingegen bei extremen Latenzen aus: Sein p99 liegt bei 38,71 ms gegenüber 74,60 ms, und sein Index wurde in 3,3 Stunden aufgebaut, gegenüber 11,1 Stunden. Für den Leitfaden bleiben beide Systeme bei allen gemessenen Perzentilen unter 100 ms.
Welche Wahl je nach Workload
Der Leitfaden schätzt, dass pgvector für Volumen bis etwa 5 bis 10 Millionen Vektoren geeignet ist, bei moderater Anfragekonkurrenz und wenn ein Team bereits PostgreSQL beherrscht. Er hebt auch die transaktionale Konsistenz zwischen relationalen Daten und Vektoren hervor, die es ermöglicht, ein Dokument und seinen Vektor in derselben Transaktion zu aktualisieren.
Umgekehrt rechtfertigt sich laut Artikel eine dedizierte Datenbank für Volumen von mehreren hundert Millionen bis mehreren Milliarden Vektoren oder für eine strenge Anforderung an extreme Latenz bei stark beanspruchten gefilterten Suchen, einem Bereich, in dem Qdrant den gemessenen Vorteil aufweist. Milvus wird für die GPU-beschleunigte Indizierung genannt und Pinecone für einen vollständig verwalteten Dienst ohne interne Administration.
