Les bases de données vectorielles ne sont plus une expérience de laboratoire. Elles sont devenues le cœur invisible des applications de recherche sémantique, de RAG et de recommandation. Et si tu penses encore que c'est un sujet de data scientist, détrompe-toi : c'est un choix d'architecture qui impacte toute ta stack.
Ce choix n'est pas neutre. Il conditionne la qualité de tes résultats, la latence perçue par tes utilisateurs et ton budget d'infrastructure. Prenons un exemple concret : un index HNSW bien réglé peut répondre en moins de 50 ms sur 10 millions de vecteurs, mais mal configuré, il peut te demander plusieurs Go de RAM pour seulement 100 000 items. Même chose pour les embeddings : passer de 384 à 1536 dimensions multiplie par quatre tes coûts de stockage, sans garantir le moindre gain de pertinence.
Dans ce dossier, on analyse d'abord ce que la mise en place d'une base vectorielle révèle de la maturité data de ton organisation. Ensuite, on détaille le rôle central des modèles d'embedding, puis on compare pgvector aux solutions dédiées comme Pinecone, Weaviate ou Milvus sur des critères opérationnels. Pour finir, on s'intéresse aux signaux que ces décisions envoient au secteur — parce que ton choix de BDD vectorielle parle de toi avant même que tu ne l'aies configurée.
Bases vectorielles : un révélateur de maturité data
Si tu penses qu'une base vectorielle est un choix technique, tu passes à côté du sujet. C'est un révélateur de la façon dont ton organisation comprend ses données et ses usages. J'ai vu des équipes déployer Milvus pour un problème que PostgreSQL avec pgvector aurait résolu en une après-midi.
Concrètement, les bases vectorielles résolvent un problème que la recherche full-text n'adresse pas : la similarité sémantique. Tu cherches "chaussures de running pour marathon" et tu obtiens des résultats qui parlent de "baskets d'entraînement longue distance". C'est là qu'un index HNSW sur des embeddings fait la différence. Mais attention : le choix de la solution, dédiée ou intégrée, en dit long sur la maturité de ta stack.
Une équipe mature commence par questionner ses données et ses usages. Combien de vecteurs ? Quelle latence ? Quelle fraîcheur ? Un exemple concret : pour 10 millions de vecteurs en 768 dimensions, un HNSW bien configuré tient dans 4 Go de RAM et répond en 20 ms. Mais si tu règles mal efConstruction et M, tu peux exploser ton budget et te traîner. Ce savoir-faire ne s'achète pas avec une licence Pinecone.
Pourquoi maintenant ? Parce que les modèles d'embedding sont devenus abordables et que le volume de données non structurées explose. Mais surtout parce que le RAG a transformé un sujet de recherche en besoin métier. Ton choix de base vectorielle est donc un indicateur : il montre si tu as réfléchi à ta stratégie de données ou si tu sautes sur la première technologie à la mode.
Un choix de BDD vectorielle ne se fait pas sur un benchmark de performance. Il se fait sur ce que tu comprends de tes données, de tes utilisateurs et de la pérennité de ton architecture.
Modèles d'embedding : le choix stratégique trop souvent négligé
La base vectorielle ne représente que 20% du résultat final. Le reste, c'est ton modèle d'embedding. Si tes vecteurs sont mauvais, ton index HNSW parfaitement réglé ne sauvera rien. Je vois trop d'équipes passer des semaines à comparer pgvector et Pinecone, puis copier-coller le modèle d'embedding du premier tutoriel venu. C'est exactement l'inverse qu'il faut faire.
Choisis ton modèle selon ton domaine. Pour des textes juridiques français, un modèle générique type OpenAI text-embedding-ada donne des résultats faméliques. J'ai vu une équipe passer sur un modèle juridique spécialisé : précision en hausse de 30% sur leur jeu de test. Teste toujours sur tes propres données. Un petit échantillon de paires similaires/dissimilaires suffit pour départager deux modèles.
La dimensionnalité, c'est un arbitrage coût/vitesse. Passer de 384 à 1536 dimensions multiplie par quatre ton coût de stockage, et la latence triple sur des volumes importants. Pour du RAG de base, des vecteurs en 768 dimensions font largement le travail. Un modèle bien calibré en 384 dimensions peut battre un gros modèle de chez OpenAI sur un domaine précis, avec un index qui tient dans moins de RAM.
Et puis, tes embeddings se dégradent avec le temps. Les usages évoluent, ton vocabulaire métier change. Si tu ne surveilles pas la dérive, tu te réveilles avec des résultats incohérents. Je recommande de figer un jeu de validation et de calculer un recall@10 automatiquement chaque semaine. Dès que la métrique chute de plus de 5%, tu sais que ton embedding ne suit plus et qu'il faut le ré-entraîner ou changer de modèle.
pgvector vs solutions dédiées : comparer sur des critères opérationnels
Premier réflexe à tuer : comparer des benchmarks de QPS. Sur 1 million de vecteurs, tout le monde s'en sort. Le vrai clivage apparaît quand tu arrives à 50 millions de vecteurs et que tu dois garantir des backups nocturnes, des ops sans dormir et un budget sans surprise.
Mon expérience : pgvector est un excellent couteau suisse. Pour un RAG interne avec 500 000 chunks, c'est largement suffisant. Mais passé quelques millions de vecteurs et des exigences de latence sous 30 ms en quasi-permanent, il ne faut pas se mentir : l'index HNSW de pgvector se dégrade, les builds d'index bloquent l'écriture, et tu passes ton temps à brasser de la RAM. Un collègue l'a traduit ainsi :
Avec des solutions dédiées, tu paies pour la tranquillité, pas pour la perfo brute.
Ta grille d'arbitrage tient en trois questions.
- Volume et latence. Si tu es au-delà de 10–20 millions de vecteurs en 768 dimensions avec un besoin de latence sous 50 ms, passe à une solution dédiée. En dessous, pgvector est un choix défendable.
- Coût sur un périmètre réaliste. Ne compare pas le prix des licences. Prends un cluster avec les quatre à cinq replicas nécessaires pour la haute dispo, le stockage d'index en RAM, et le temps que ton équipe passera à tuner. Un exemple : 100 millions de vecteurs en 1536 dimensions, c'est environ 614 Go d'index HNSW. En cloud managé, ça chiffre vite. Sur pgvector, tu auras les coûts de stockage mais aussi le coût d'ingénierie pour maintenir des index à jour.
- Compétences. Une solution dédiée ne gomme pas la complexité. Tu dois quand même comprendre HNSW, la distance choisie, les stratégies de quantisation. La différence ? Tu as moins de tables à maintenir et plus d'outils de monitoring. Par contre, tu ajoutes un système à apprendre et une nouvelle dépendance à ton infra.
Franchement, à une époque où toutes les BDD ajoutent leur module vectoriel, la question n'est plus "quelle base vectorielle" mais "est-ce que ce volume justifie une brique de plus dans ma stack ?". Pour la plupart des projets web, non. Pour les plateformes qui vivent de la similarité à grande échelle, oui — et tu le sauras quand la recherche full-text + vectoriel ne suffira plus.
Ce que nos choix vectoriels disent de notre secteur
Ton choix de base de données vectorielle en dit plus sur ta culture d'entreprise que sur ta stack technique. C'est un miroir : celui qui déploie Pinecone pour un prototype sans données réelles ne cherche pas à résoudre un problème, il cherche à impressionner.
J'ai vu des équipes mettre en production des BDD vectorielles dédiées pour un catalogue de 50 000 items. PostgreSQL avec pgvector suffisait largement. Le résultat ? Une facture cloud multipliée par cinq et une latence pire qu'un simple index BM25. La course à la solution vectorielle est le nouveau « blockchain pour tout ».
Pour construire quelque chose de durable, commence par mesurer ton besoin réel. Pas en dimensions d'embedding, mais en questions métier. Que veux-tu que tes utilisateurs trouvent ? À quelle fréquence ? Avec quelle fraîcheur ? Un exemple concret : pour un RAG sur ta doc interne, des embeddings en 384 dimensions suffisent souvent avec un modèle bien entraîné. Tu réduis la RAM de 75% par rapport à du 768, et sur 95% des requêtes, la pertinence reste identique.
Un choix de BDD vectorielle ne se fait pas sur un benchmark de performance. Il se fait sur une estimation honnête du volume, de la latence et de la fréquence de mise à jour.
Le secteur se moque de savoir si tu utilises Milvus ou Weaviate. Ce qu'il regarde, c'est si tu as compris que la similarité vectorielle n'est qu'une brique. La vraie valeur est dans la qualité de tes embeddings, la construction de ta requête et l'hybridation avec la recherche full-text. Ceux qui survivront ne seront pas ceux qui ont le plus gros index, mais ceux qui savent pourquoi ils en ont besoin.
Conclusion
Si tu es arrivé jusqu'ici, tu as compris une chose : une base vectorielle n'est pas un composant que tu branches et que tu oublies. C'est un engagement. Ton choix d'embeddings, d'index et d'infrastructure va déterminer la qualité de tes résultats, ta latence et ta facture cloud.
Prenons un cas réel : pour 20 millions de documents, un modèle d'embedding de 1536 dimensions te demande environ 30 Go de stockage vectoriel. Avec un modèle de 384 dimensions et un index HNSW bien réglé, tu divises par quatre tes coûts et par deux ta latence. Mais trop d'équipes tombent dans le piège du 'le plus gros modèle possible'. Résultat : des POC qui traînent, des budgets qui explosent, et un passage en production repoussé aux calendes grecques.
Ce que le choix d'une BDD vectorielle révèle, c'est ta maturité data. Sais-tu quel est ton volume réel de vecteurs ? Quelle fraîcheur de données tu exiges ? Quand une recherche hybride full-text + vectorielle est plus pertinente qu'un simple RAG ? Si tu n'as pas répondu à ces questions, aucun moteur vectoriel ne te sauvera. Les solutions dédiées comme Pinecone ou Weaviate simplifient le démarrage, mais elles ne t'exemptent pas de penser tes embeddings et ta stratégie d'index.
Mon verdict est simple : si tu débutes, commence par pgvector. C'est gratuit, intégré à PostgreSQL, et ça couvre 80% des besoins. Tu passeras à une solution dédiée quand tu atteindras des volumes critiques — et uniquement avec une migration réfléchie. Dans tous les cas, souviens-toi : une base vectorielle est un avantage durable seulement si tu maîtrises coûts, latence et maintenabilité. Le reste, c'est de la poudre aux yeux.