Faut-il stocker ses vecteurs d’embeddings dans une base PostgreSQL grâce à l’extension pgvector, ou confier cette tâche à une base de données vectorielle dédiée ? Un guide technique propose de répondre à la question avec des mesures de performance plutôt qu’avec des arguments de principe, en comparant pgvector à Qdrant.
- pgvector stocke les embeddings dans PostgreSQL et permet de les interroger en SQL.
- Dans l’étude, PostgreSQL avec pgvectorscale traite 471,57 requêtes par seconde, contre 41,47 pour Qdrant.
- Qdrant offre des latences extrêmes plus basses et construit son index plus vite.
- pgvector suffit jusqu’à 5 à 10 millions de vecteurs, tandis qu’une base dédiée s’impose à très grande échelle.
Deux architectures, un même objectif
pgvector est une extension open source de PostgreSQL, en version 0.8.6, compatible avec PostgreSQL 13 et les versions ultérieures, selon son dépôt GitHub officiel. Elle ajoute à la base un type de colonne dédié aux vecteurs, ainsi que des recherches exactes et approximatives de plus proches voisins. Concrètement, un embedding, c’est-à-dire la représentation numérique d’un contenu sous forme de vecteur, peut être stocké dans la même table que les données auxquelles il se rapporte, et interrogé avec le langage SQL habituel. Cinq fonctions de distance sont proposées, dont le cosinus et le produit scalaire.
Une base de données vectorielle dédiée est, à l’inverse, un service distinct, doté de son propre moteur de stockage et conçu autour de la recherche vectorielle. Le guide cite notamment Pinecone, Qdrant, Weaviate, Milvus et ChromaDB. Ce choix d’architecture implique de déployer, surveiller et sauvegarder un système supplémentaire, et de le maintenir synchronisé avec la base qui contient les données de référence.
Des mesures locales, puis à grande échelle
Le guide propose un test reproductible sur un ordinateur portable, avec Docker, Python 3.10 ou une version ultérieure et environ 8 Go de RAM libre. Le jeu de données est synthétique : 100 000 vecteurs de 1536 dimensions, soit la taille d’un modèle d’embeddings courant, chargés dans les deux systèmes avec les mêmes paramètres d’index HNSW. Sur un tel matériel, les latences se situent, selon l’auteur, entre quelques millisecondes et quelques dizaines de millisecondes, avec de fortes variations selon le processeur et la mémoire disponibles. Ce volume reste trop modeste pour tirer une conclusion de production.
Pour cette question, le guide s’appuie sur une étude publiée par Tiger Data. Elle porte sur 50 millions d’embeddings Cohere de 768 dimensions, testés sur des machines AWS r6id.4xlarge (16 vCPU, 128 Go de RAM), avec une version modifiée de l’outil ANN-Benchmarks. Le guide souligne un point important : le test a été réalisé avec pgvector associé à pgvectorscale, une extension de Timescale qui ajoute un autre type d’index, StreamingDiskANN, et non avec pgvector seul.
Selon ces résultats, à un rappel de 99 %, PostgreSQL avec pgvectorscale atteint 471,57 requêtes par seconde, contre 41,47 pour Qdrant. La latence médiane est presque identique, avec 31,07 ms contre 30,75 ms. Qdrant se distingue en revanche sur les latences extrêmes : son p99 est de 38,71 ms, contre 74,60 ms, et son index a été construit en 3,3 heures, contre 11,1 heures. Pour le guide, les deux systèmes restent sous les 100 ms à tous les percentiles mesurés.
Quel choix selon la charge de travail
Le guide estime que pgvector convient à des volumes allant jusqu’à environ 5 à 10 millions de vecteurs, à une concurrence de requêtes modérée et lorsqu’une équipe maîtrise déjà PostgreSQL. Il met aussi en avant la cohérence transactionnelle entre données relationnelles et vecteurs, qui permet de mettre à jour un document et son vecteur dans une même transaction.
À l’inverse, une base dédiée se justifie, selon l’article, pour des volumes de plusieurs centaines de millions à plusieurs milliards de vecteurs, ou pour une contrainte stricte de latence extrême lors de recherches filtrées très sollicitées, domaine où Qdrant présente l’avantage mesuré. Milvus est cité pour l’indexation accélérée par GPU, et Pinecone pour un service entièrement géré, sans administration à assurer en interne.
