Choisir sa base vectorielle selon ce qui casse en premier

Presque tout système de retrieval devrait démarrer avec pgvector dans le Postgres que vous exploitez déjà, et la question de sélection n'est pas "quelle base vectorielle est la plus rapide" mais "quel mode de défaillance m'atteint en premier". Les chiffres publiés de recall et de QPS convergent d'un moteur à l'autre aux échelles où la plupart des équipes opèrent réellement. Ce qui ne converge pas, c'est ce qui se passe quand vous ajoutez un filtre de tenant à chaque requête, quand l'index doit être reconstruit pendant les heures ouvrées, ou quand le graphe HNSW ne tient plus en RAM. Ce sont ces événements qui forcent une migration, et chaque moteur échoue sur un événement différent.

La manière honnête de comparer des magasins vectoriels est donc de raisonner à rebours depuis la panne. Choisissez la défaillance que vous rencontrerez en premier, puis choisissez le moteur qui ne l'a pas. Tout le reste n'est qu'une grille de fonctionnalités.

Les quatre choses qui cassent vraiment

Sur les systèmes RAG et de mémoire d'agent en production, quatre symptômes expliquent presque toutes les migrations hors du choix initial :

• Temps de construction et de reconstruction de l'index. Vous changez le modèle d'embedding, ou la dimension, ou l'opérateur de distance, et vous devez maintenant reconstruire un index de plus proches voisins approché sur chaque ligne. À un million de vecteurs, c'est le temps d'un café. À cinquante millions, c'est une fenêtre de maintenance, et vous devez décider si l'ancien index sert le trafic pendant que le nouveau se construit.
• Recall en recherche filtrée. Presque personne n'exécute une requête vectorielle non filtrée en production. Les requêtes réelles sont "plus proches voisins where tenant_id = X and status = active and updated_at > Y". Les index par graphe sont conçus pour le cas non filtré, et un filtre sélectif peut faire qu'une recherche ANN retourne moins que les k lignes demandées, silencieusement. C'est un problème de correction déguisé en problème de pertinence.
• Mémoire du graphe contre RAM. HNSW est un graphe, et il veut vivre en mémoire. Quand le graphe plus votre working set dépassent ce que l'instance possède, la latence ne se dégrade pas en douceur, elle tombe d'une falaise dès que la machine se met à lire des pages d'index sur disque à chaque sonde.
• Retard de fraîcheur sous charge d'écriture. La mémoire d'agent et l'outillage de support écrivent en continu. Chaque insertion mute le graphe, la maintenance de l'index entre en concurrence avec le trafic de requêtes, et l'écart entre "nous avons stocké le fait" et "le fait est récupérable" commence à compter pour la correction plutôt que pour le ressenti.

Notez ce qui n'est pas dans cette liste : les requêtes par seconde brutes. Si vous servez du retrieval à un modèle qui passe ensuite deux secondes à générer, dix millisecondes d'écart sur la latence de recherche sont du bruit. The latency that hurts in RAG lives in the number of round trips, pas dans la sonde ANN.

pgvector : le bon défaut, et ses vrais plafonds

L'argument pour pgvector n'est pas qu'il gagne les benchmarks. C'est que vos embeddings vivent dans la même transaction que la ligne qu'ils décrivent, que vos filtres sont du SQL ordinaire sur des colonnes déjà indexées, que votre stratégie de sauvegarde et de point-in-time recovery est celle que vous exploitez déjà, et que votre astreinte sait déjà lire un EXPLAIN. Cette combinaison vaut beaucoup de p99.

Les plafonds sont précis et méritent d'être mémorisés, parce que la peur vague qu'ils inspirent cause plus de migrations prématurées que les plafonds eux-mêmes n'en causeront jamais :

• Les limites de dimension sont des limites d'index, pas de colonne. Une colonne vector accepte jusqu'à 16 000 dimensions, mais HNSW et IVFFlat n'indexent que jusqu'à 2 000. Avec halfvec (flottants 16 bits), vous indexez jusqu'à 4 000 dimensions pour environ la moitié du stockage. bit indexe jusqu'à 64 000 dimensions pour la quantization binaire, et sparsevec gère jusqu'à 1 000 éléments non nuls. Un embedding en 3 072 dimensions n'est pas une raison de quitter Postgres, c'est une raison de caster vers halfvec dans l'expression d'index.
• Les requêtes filtrées ont cessé d'être une falaise en 0.8.0. L'ancien échec était réel : un scan HNSW retournait ses candidats ef_search, votre clause WHERE en supprimait la plupart, et vous receviez trois lignes quand vous en demandiez dix. pgvector 0.8.0 a ajouté les scans d'index itératifs, qui continuent de balayer jusqu'à obtenir assez de lignes survivantes. hnsw.iterative_scan = strict_order préserve l'ordre exact des distances, relaxed_order échange un peu d'ordre contre un meilleur recall. Si votre modèle mental du filtrage de pgvector date de 2024, il est périmé.
• La mémoire de construction est ce qui mord vraiment. HNSW se construit en mémoire quand le graphe tient dans maintenance_work_mem, et retombe sur un chemin sur disque beaucoup plus lent quand ce n'est pas le cas. Le correctif est de l'augmenter pour la construction et d'utiliser des workers parallèles, mais il existe une taille au-delà de laquelle vous planifiez une reconstruction plutôt que d'en lancer une.
• Les voisins bruyants sont un problème d'architecture. Une construction ANN qui sature le CPU de l'instance servant votre tunnel de paiement est le mode de défaillance qui n'a rien à voir avec les vecteurs. Un réplica en lecture ou une instance séparée le résout, et c'est aussi le moment où pgvector cesse d'être gratuit.

Sur AWS en particulier, Aurora PostgreSQL avec pgvector est un magasin vectoriel de premier rang pour Bedrock Knowledge Bases, donc ce choix ne vous coûte aucune fonctionnalité de RAG managé. J'ai détaillé le volet coût dans the OpenSearch Serverless to Aurora migration post, avec une réserve plus bas : le côté OpenSearch de cette comparaison a changé en mai 2026.

OpenSearch : vous achetez un moteur de recherche, utilisez-le comme tel

Choisir OpenSearch uniquement comme magasin vectoriel est la manière coûteuse d'obtenir de la recherche vectorielle. Le choisir parce que vous avez besoin de recherche, et que les vecteurs sont l'un des éléments avec lesquels vous cherchez, est une décision différente et bien meilleure.

Ce qu'il vous donne qu'un magasin vectoriel pur n'a pas : une vraie recherche lexicale à côté de l'ANN, si bien que le retrieval hybride combinant BM25 et similarité vectorielle est une requête, pas une architecture. La correspondance exacte de mots-clés pour les références de pièces, codes d'erreur et identifiants sur lesquels les embeddings sont notoirement mauvais. Des agrégations, du faceting, et un moteur de filtrage conçu pour les attributs à forte cardinalité plutôt que rajouté après coup. Et les vecteurs binaires, que sur Bedrock Knowledge Bases seules les deux options OpenSearch supportent.

L'argument contre lui a historiquement été le plancher : OpenSearch Serverless facturait en OCUs avec un minimum de production qui coûtait de l'argent réel avant d'indexer le moindre document. C'est l'argument sur lequel mon billet de migration était bâti, et il appelle une correction. La nouvelle génération d'OpenSearch Serverless est passée en disponibilité générale le 28 mai 2026 avec compute et stockage totalement découplés, le scale-to-zero, et un autoscaling qu'AWS décrit comme vingt fois plus rapide que la génération précédente. AWS annonce jusqu'à 60 pour cent d'économies par rapport à un cluster provisionné pour la charge de pointe. Si votre charge est en rafales, et le retrieval agentique est extrêmement en rafales, l'ancien argument du plancher ne s'applique plus sous la forme où je l'avais formulé.

Ce qui casse encore : c'est un système distribué avec des shards, des replicas et un état de cluster, et il finira par vous demander de penser aux trois. Le dimensionnement des shards pour des charges vectorielles n'est pas le même que pour des logs. Et une reconstruction est un reindex, ce qui signifie planifier la capacité pour deux copies de l'index.

S3 Vectors : un tier de stockage qui répond aux requêtes, pas un tier de service

S3 Vectors a atteint la disponibilité générale le 2 décembre 2025 à quarante fois l'échelle de la preview : jusqu'à deux milliards de vecteurs par index et dix mille index par vector bucket, avec dix-sept régions supplémentaires ajoutées en mars 2026. AWS chiffre la réduction de coût face à l'exploitation d'une base vectorielle à 90 pour cent au maximum, et la raison est structurelle plutôt que promotionnelle : pas de cluster, pas de compute provisionné, pas de facturation à vide.

Le chiffre qui décide s'il convient est le profil de latence. AWS documente les requêtes peu fréquentes comme répondant en moins d'une seconde, et les requêtes plus fréquentes autour de 100 millisecondes ou moins. Lisez cela comme un effet de cache chaud, puis soyez honnête sur votre trafic : un assistant de support qui reçoit quarante questions par heure ne garde rien au chaud. Moins d'une seconde convient à un job de synthèse nocturne et pas à un chat interactif où le modèle a ensuite besoin de ses propres deux secondes.

Là où c'est réellement la bonne réponse : les tiers vectoriels froids ou d'archive, les index par tenant quand les tenants sont nombreux et le trafic de chacun clairsemé, les Bedrock Knowledge Bases pilotées par le coût avec des budgets de latence tolérants, et tout cas où l'alternative était de payer un cluster inactif. Il se compose bien comme second tier sous un magasin chaud, et c'est ainsi que je l'utiliserais plutôt qu'en remplacement intégral.

Qdrant, Milvus, Pinecone : quand la charge l'emporte

Vous quittez Postgres pour un moteur dédié quand la charge vectorielle a cessé d'être une fonctionnalité de votre application pour devenir l'application. Trois formes de cela :

Qdrant est celui à saisir quand le filtrage est le problème. Ses index de payload et son HNSW filtrable sont conçus pour le cas auquel le scan itératif de pgvector se contente de survivre : des filtres très sélectifs sur chaque requête, à haut débit. Il embarque aussi la quantization scalaire, produit et binaire, qui est la manière pratique de garder un gros index résident en mémoire. Pour un magasin de mémoire d'agent multi-tenant avec filtres par tenant sur chaque lecture, c'est une raison défendable d'exploiter une autre base de données.

Milvus est la réponse à l'échelle du milliard. L'indexation sur disque (DiskANN) signifie que le working set n'a pas à tenir en RAM, ce qui change la facture matérielle à cette taille. La contrepartie est opérationnelle : c'est un système distribué avec des rôles séparés de coordinateur, de requête, de données et d'index, et l'exploiter en production est une décision de staffing avant d'être une décision technique. Sous quelques centaines de millions de vecteurs, cette complexité vous rapporte très peu.

Pinecone est l'option acheter-plutôt-que-construire, et il faut l'évaluer comme n'importe quel SaaS : sur la charge opérationnelle qu'il retire plutôt que sur la latence. La tarification serverless découple le stockage des lectures et écritures sans coût à vide, ce qui convient aux charges en pics et rend les petits déploiements réellement bon marché. Ce que vous abandonnez, c'est le contrôle des modes de défaillance, et vous prenez l'egress et le couplage fournisseur. C'est aussi un magasin supporté par Bedrock Knowledge Bases, donc ce n'est pas une sortie du chemin RAG managé d'AWS.

La longue traîne, brièvement

Weaviate est ce qui se rapproche le plus d'un magasin RAG tout équipé : modules de vectorisation intégrés, recherche hybride, et un modèle schema-first. Attirant si vous voulez des opinions fournies, moins si vous avez déjà un pipeline d'embedding. Chroma est un outil de prototypage qui l'assume, et chaque déploiement sérieux que j'ai vu a fini par en migrer. Redis avec similarité vectorielle est excellent quand les vecteurs sont éphémères, sessions, mémoire d'agent à court terme, caches sémantiques, et terrible comme système de référence. MongoDB Atlas Vector Search est à Mongo ce que pgvector est à Postgres : correct si vos documents y vivent déjà, et une mauvaise raison d'adopter Mongo s'ils n'y vivent pas. Redis Enterprise Cloud comme MongoDB Atlas sont des magasins supportés par Bedrock Knowledge Bases.

La table de décision

Les déclencheurs qui signifient vraiment "quittez pgvector maintenant"

Pas l'échelle dans l'abstrait. Ceux-ci :

• Votre reconstruction HNSW ne tient plus dans une fenêtre de maintenance acceptable, et vous avez déjà augmenté maintenance_work_mem et utilisé des workers parallèles.
• Le recall filtré reste insuffisant après avoir activé les scans itératifs et réglé ef_search, parce que vos filtres sont assez sélectifs pour que le graphe soit la mauvaise structure.
• Le working set de l'index dépasse la mémoire de l'instance et la taille d'instance supérieure coûte plus cher qu'un moteur dédié.
• La recherche vectorielle affame votre charge transactionnelle, et un réplica en lecture n'offre pas assez de séparation.
• Vous avez besoin du classement hybride lexical plus vectoriel comme requête de premier rang plutôt que comme deux recherches fusionnées dans le code applicatif. Celui-là pointe spécifiquement vers OpenSearch.

Si aucun de ces points n'est vrai, la migration que vous planifiez est une préférence, pas une exigence. L'équipe qui livre une couche de retrieval fonctionnelle sur la base qu'elle exploite déjà, et ne bouge que quand l'un de ces déclencheurs se produit, arrive en production nettement plus tôt que l'équipe qui a passé son premier sprint à choisir.

Ce qu'il faut retenir

Démarrez sur pgvector, et connaissez ses quatre plafonds assez précisément pour distinguer une vraie limite du folklore. Passez à OpenSearch quand vous avez besoin de recherche plutôt que de similarité, et refaites la comparaison de coût face à l'offre serverless nouvelle génération plutôt qu'à l'ancien plancher OCU. Utilisez S3 Vectors comme tier froid et pour les index par tenant clairsemés, pas comme chemin de service interactif. Saisissez Qdrant quand le filtrage domine, Milvus passé le point où la RAM fixe la facture, et Pinecone quand vous préférez acheter les opérations plutôt que les exécuter. Choisissez selon la panne que vous rencontrerez en premier, parce que c'est la seule variable de cette comparaison qui diffère réellement d'un moteur à l'autre.

À lire ensuite

• Agent Memory Is a Database Problem, Not a Prompt Problem, sur pourquoi la couche de stockage décide de ce que votre agent peut mémoriser.
• Knowledge Base Chunking Is Where Your RAG Quality Dies, sur le problème de retrieval qu'aucune base vectorielle ne règle pour vous.

Pour le versant infrastructure de l'exploitation de Postgres et de clusters de recherche en production, les notes de terrain cloud vivent sur ercan.cloud, et le hub est sur ercanermis.com.

Références

• pgvector on GitHub, vector types, index types, and dimension limits.
• pgvector 0.8.0 release announcement, iterative index scans and filtering improvements.
• The next generation of Amazon OpenSearch Serverless is now generally available, AWS What's New, 28 May 2026.
• Amazon S3 Vectors is now generally available with 40 times the scale of preview, AWS What's New, 2 December 2025.
• Working with S3 Vectors and vector buckets, Amazon S3 User Guide.
• Prerequisites for using a vector store you created for a knowledge base, Amazon Bedrock User Guide.
• Approximate k-NN search, OpenSearch documentation.
• Filtering, Qdrant documentation.
• DiskANN-based on-disk index, Milvus documentation.
• Pinecone pricing, serverless read unit, write unit, and storage model.