RIP les bases de données vectorielles : la victoire du pragmatisme

Il y a encore dix-huit mois, concevoir une architecture RAG (Retrieval-Augmented Generation) semblait impensable sans adopter une base de données vectorielle dédiée. Pinecone, Weaviate, Qdrant ou Milvus levaient des dizaines de millions de dollars, propulsés au rang de briques indispensables du renouveau de l'intelligence artificielle.

Aujourd'hui, l'euphorie retombe et un constat pragmatique s'impose : pour l'immense majorité des projets web et logiciels, les bases vectorielles autonomes sont déjà superflues. Doit-on pour autant annoncer leur mort définitive ? Pas tout à fait, mais leur statut de standard par défaut s'est effondré.

L'illusion de la spécialisation à tout prix

Au départ, l'argument tenait la route. L'indexation vectorielle (HNSW, IVFFlat) et le calcul de similarité cosinus nécessitent des algorithmes spécifiques. Les moteurs relationnels traditionnels n'étaient tout simplement pas taillés pour encaisser le volume soudain d'embeddings générés par OpenAI ou Hugging Face.

Cependant, ajouter une base de données distincte à une pile technique introduit des frictions majeures que tout développeur full-stack connaît bien :

• La synchronisation des états : Devoir maintenir la cohérence entre votre base relationnelle primaire et une base vectorielle externe est une source garantie de bugs et de complexité distribuée.
• L'absence de jointures natives : Dans une application réelle, une recherche sémantique s'accompagne presque toujours de filtres stricts (droits d'accès, appartenance à un compte client, statut de publication). Filtrer côté base vectorielle reste souvent rigide et coûteux.
• Le surcoût opérationnel : Un nouveau cluster à monitorer, de nouvelles règles de sécurité à paramétrer et une facture d'infrastructure supplémentaire.

La riposte des généralistes : l'effet pgvector

L'histoire du génie logiciel se répète régulièrement : dès qu'un besoin novateur se démocratise, les technologies établies l'absorbent. C'est exactement le sort réservé aux vecteurs avec l'essor fulgurant de l'extension pgvector pour PostgreSQL.

Aujourd'hui, avec la prise en charge d'index HNSW performants, une simple instance Postgres peut indexer et requêter des millions de vecteurs en mémoire avec des latences inférieures à 20 millisecondes. Redis, Elasticsearch, MongoDB et même SQLite (via sqlite-vec) ont rapidement emboîté le pas.

Dès lors, le calcul devient évident pour une équipe d'ingénierie : pourquoi administrer une base supplémentaire quand on peut stocker un vecteur directement dans une colonne à côté du profil utilisateur ou du document source ?

Quand une base dédiée reste-t-elle pertinente ?

Enterrer complètement ces solutions spécialisées serait injuste. Elles conservent une pertinence technique indiscutable dans certains scénarios limites :

• Des volumétries massives dépassant les dizaines de millions de vecteurs à interroger en continu.
• Des contraintes de débit et de latence extrêmes (sub-5ms) à très forte concurrence.
• Des besoins de recherche hybride avancée (dense et sparse) prêts à l'emploi sans réglages complexes.

Le problème de fond est économique : ces cas d'usage extrêmes ne concernent que 1 à 5 % des entreprises qui déploient de l'IA.

La leçon pour les développeurs

Ce reflux rappelle l'importance du concept de « Boring Technology » : privilégier des outils matures, stables et polyvalents plutôt que de fragmenter son architecture au gré des effets de mode.

Si vous concevez aujourd'hui une fonctionnalité d'IA générative ou de recherche contextuelle, résistez au réflexe d'empiler un nouveau service SaaS. Utilisez ce que vous avez déjà sous la main : votre base de données relationnelle préférée est très probablement largement suffisante.