Moet je je embedding-vectoren opslaan in een PostgreSQL-database dankzij de extensie pgvector, of deze taak toevertrouwen aan een gespecialiseerde vectoriële database? Een technische gids wil de vraag beantwoorden met prestatiemetingen in plaats van principiële argumenten, door pgvector te vergelijken met Qdrant.
Twee architecturen, eenzelfde doel
pgvector is een open source-extensie voor PostgreSQL, in versie 0.8.6, compatibel met PostgreSQL 13 en latere versies, volgens zijn officiële GitHub-repository. Het voegt een specifiek kolomtype voor vectoren toe aan de database, evenals exacte en benaderende zoekopdrachten voor de dichtstbijzijnde buren. Concreet kan een embedding, dat wil zeggen de numerieke representatie van inhoud in vectorvorm, worden opgeslagen in dezelfde tabel als de gegevens waarnaar het verwijst, en worden bevraagd met de gebruikelijke SQL-taal. Er worden vijf afstandsfuncties aangeboden, waaronder cosinus en inwendig product.
Een gespecialiseerde vectoriële database is daarentegen een aparte dienst, met zijn eigen opslagmotor en ontworpen rond vectorzoeken. De gids noemt onder meer Pinecone, Qdrant, Weaviate, Milvus en ChromaDB. Deze architectuurkeuze impliceert het implementeren, monitoren en back-uppen van een extra systeem, en het gesynchroniseerd houden met de database die de referentiegegevens bevat.
Metingen lokaal, dan op grote schaal
De gids stelt een reproduceerbare test voor op een laptop, met Docker, Python 3.10 of een latere versie en ongeveer 8 GB vrij RAM. De dataset is synthetisch: 100.000 vectoren van 1536 dimensies, de grootte van een gangbaar embedding-model, geladen in beide systemen met dezelfde HNSW-indexparameters. Op dergelijke hardware liggen de latenties volgens de auteur tussen enkele milliseconden en enkele tientallen milliseconden, met sterke variaties afhankelijk van de beschikbare processor en geheugen. Dit volume blijft te bescheiden om een productieconclusie te trekken.
Voor deze vraag baseert de gids zich op een studie gepubliceerd door Tiger Data. Deze gaat over 50 miljoen Cohere-embeddings van 768 dimensies, getest op AWS r6id.4xlarge-machines (16 vCPU, 128 GB RAM), met een aangepaste versie van het ANN-Benchmarks-hulpmiddel. De gids benadrukt een belangrijk punt: de test werd uitgevoerd met pgvector gecombineerd met pgvectorscale, een extensie van Timescale die een ander type index toevoegt, StreamingDiskANN, en niet met pgvector alleen.
Volgens deze resultaten bereikt PostgreSQL met pgvectorscale bij een recall van 99% 471,57 queries per seconde, tegen 41,47 voor Qdrant. De mediane latentie is bijna identiek, met 31,07 ms tegen 30,75 ms. Qdrant onderscheidt zich daarentegen op extreme latenties: zijn p99 is 38,71 ms, tegen 74,60 ms, en zijn index werd gebouwd in 3,3 uur, tegen 11,1 uur. Voor de gids blijven beide systemen onder de 100 ms op alle gemeten percentielen.
Welke keuze afhankelijk van de werklast
De gids schat dat pgvector geschikt is voor volumes tot ongeveer 5 à 10 miljoen vectoren, bij een gematigde queryconcurrentie en wanneer een team PostgreSQL al beheerst. Hij benadrukt ook de transactionele consistentie tussen relationele gegevens en vectoren, waardoor een document en zijn vector in dezelfde transactie kunnen worden bijgewerkt.
Omgekeerd rechtvaardigt een gespecialiseerde database zich volgens het artikel voor volumes van enkele honderden miljoenen tot miljarden vectoren, of voor een strikte beperking van extreme latentie bij zeer belaste gefilterde zoekopdrachten, een domein waar Qdrant het gemeten voordeel heeft. Milvus wordt genoemd voor GPU-versnelde indexering, en Pinecone voor een volledig beheerde dienst zonder interne administratie.
