Conviene archiviare i propri vettori di embedding in un database PostgreSQL tramite l’estensione pgvector, o affidare questo compito a un database vettoriale dedicato? Una guida tecnica propone di rispondere alla domanda con misurazioni delle prestazioni piuttosto che con argomentazioni di principio, confrontando pgvector con Qdrant.
Due architetture, un obiettivo comune
pgvector è un’estensione open source di PostgreSQL, in versione 0.8.6, compatibile con PostgreSQL 13 e versioni successive, secondo il suo repository GitHub ufficiale. Aggiunge al database un tipo di colonna dedicato ai vettori, oltre a ricerche esatte e approssimate dei vicini più prossimi. In pratica, un embedding, ovvero la rappresentazione numerica di un contenuto sotto forma di vettore, può essere archiviato nella stessa tabella dei dati a cui si riferisce e interrogato con il consueto linguaggio SQL. Sono proposte cinque funzioni di distanza, tra cui coseno e prodotto scalare.
Un database vettoriale dedicato è, al contrario, un servizio separato, dotato del proprio motore di archiviazione e progettato intorno alla ricerca vettoriale. La guida cita in particolare Pinecone, Qdrant, Weaviate, Milvus e ChromaDB. Questa scelta architetturale implica il dispiegamento, il monitoraggio e il backup di un sistema aggiuntivo, mantenendolo sincronizzato con il database che contiene i dati di riferimento.
Misure locali, poi su larga scala
La guida propone un test riproducibile su un computer portatile, con Docker, Python 3.10 o versione successiva e circa 8 GB di RAM libera. Il dataset è sintetico: 100.000 vettori di 1536 dimensioni, corrispondenti alla dimensione di un comune modello di embedding, caricati nei due sistemi con gli stessi parametri di indice HNSW. Su un hardware del genere, le latenze si attestano, secondo l’autore, tra pochi millisecondi e qualche decina di millisecondi, con forti variazioni a seconda del processore e della memoria disponibili. Questo volume rimane troppo modesto per trarre una conclusione valida per la produzione.
Per questa domanda, la guida si basa su uno studio pubblicato da Tiger Data. Lo studio riguarda 50 milioni di embedding Cohere di 768 dimensioni, testati su macchine AWS r6id.4xlarge (16 vCPU, 128 GB di RAM), con una versione modificata dello strumento ANN-Benchmarks. La guida sottolinea un punto importante: il test è stato condotto con pgvector associato a pgvectorscale, un’estensione di Timescale che aggiunge un altro tipo di indice, StreamingDiskANN, e non con pgvector da solo.
Secondo questi risultati, con un richiamo del 99%, PostgreSQL con pgvectorscale raggiunge 471,57 richieste al secondo, contro 41,47 di Qdrant. La latenza mediana è quasi identica, con 31,07 ms contro 30,75 ms. Qdrant si distingue invece per le latenze estreme: il suo p99 è di 38,71 ms, contro 74,60 ms, e il suo indice è stato costruito in 3,3 ore, contro 11,1 ore. Per la guida, entrambi i sistemi rimangono sotto i 100 ms in tutti i percentili misurati.
Quale scelta in base al carico di lavoro
La guida ritiene che pgvector sia adatto a volumi fino a circa 5-10 milioni di vettori, con una concorrenza di richieste moderata e quando un team ha già padronanza di PostgreSQL. Sottolinea anche la coerenza transazionale tra dati relazionali e vettori, che consente di aggiornare un documento e il suo vettore nella stessa transazione.
Al contrario, un database dedicato si giustifica, secondo l’articolo, per volumi di diverse centinaia di milioni o miliardi di vettori, o per un vincolo rigoroso di latenza estrema durante ricerche filtrate molto sollecitate, ambito in cui Qdrant mostra il vantaggio misurato. Milvus è citato per l’indicizzazione accelerata da GPU, e Pinecone per un servizio completamente gestito, senza necessità di amministrazione interna.
