pgvectorscale : vers une architecture IA unifiée dans PostgreSQL, sans Elasticsearch ni Pinecone

Depuis l'essor des applications basées sur les LLM, un schéma architectural s'est imposé presque par défaut : PostgreSQL pour les données relationnelles, et un moteur vectoriel externe (Pinecone, Elasticsearch, Weaviate…) pour la recherche sémantique. Ce doublon technologique a un coût — en infrastructure, en complexité opérationnelle, et en cohérence des données. pgvectorscale, l'extension développée par Tiger Data (anciennement Timescale), propose une réponse sérieuse à ce problème. Voici pourquoi cela mérite votre attention.

Cet article s'appuie sur l'analyse de Christophe Pettus publiée sur postgr.es.

Le problème structurel de pgvector à grande échelle

pgvector est l'extension de référence pour la recherche vectorielle dans PostgreSQL. Elle introduit un type vector et plusieurs stratégies d'indexation, dont HNSW (Hierarchical Navigable Small World), qui est aujourd'hui le choix dominant en production pour sa qualité de rappel.

Mais HNSW souffre d'un défaut structurel : le graphe d'index doit résider en mémoire (dans shared_buffers ou le page cache du système d'exploitation) pour offrir des performances acceptables. Ce n'est pas un bug, c'est une conséquence directe de la façon dont l'algorithme traverse le graphe — de manière quasi-aléatoire, ce qui est le pire scénario possible pour un système de cache.

Concrètement : avec des embeddings de dimension 1536 (le format courant d'OpenAI), on atteint la limite des 50 millions de vecteurs avant que les coûts mémoire ne deviennent prohibitifs. Au-delà, les options classiques sont :

• Passer à Pinecone ou un équivalent dédié
• Augmenter la RAM du serveur (coûteux)
• Fragmenter manuellement (complexe)
• Adopter pgvectorscale

Ce que pgvectorscale apporte concrètement

pgvectorscale introduit un nouvel algorithme d'indexation : StreamingDiskANN, une adaptation de l'algorithme DiskANN de Microsoft Research, conçu explicitement pour fonctionner sur disque sans sacrifier les performances.

Un index pensé pour le disque

Contrairement à HNSW, DiskANN organise ses traversées de graphe de manière à maximiser la localité des accès disque. Résultat : les performances restent stables même quand l'index ne tient pas en RAM. Pour des workloads à très grande échelle, le gain en coût infrastructure peut être substantiel — Tiger Data annonce des économies allant jusqu'à 75 % comparé à des solutions comme Pinecone.

Une intégration native à PostgreSQL

pgvectorscale s'installe comme n'importe quelle extension PostgreSQL et se superpose à pgvector. La syntaxe reste familière :

CREATE INDEX ON documents
USING diskann (embedding vector_cosine_ops);

Vos requêtes de recherche sémantique existantes continuent de fonctionner, sans modification applicative majeure.

La recherche hybride sans sidecar Elasticsearch

C'est peut-être le point le plus stratégique. Dans de nombreuses architectures actuelles, Elasticsearch (ou OpenSearch) est maintenu uniquement pour la recherche full-text BM25, en complément de PostgreSQL. pgvectorscale s'inscrit dans un écosystème Tiger Data qui vise à éliminer ce besoin.

BM25 dans PostgreSQL avec pg_textsearch

Tiger Data a publié pg_textsearch, une implémentation native de BM25 pour PostgreSQL. Combinée à pgvectorscale, elle permet de réaliser de la recherche hybride (sémantique + lexicale) directement dans Postgres, via une fusion de scores de type RRF (Reciprocal Rank Fusion) :

-- Recherche hybride : sémantique + BM25
SELECT id, title,
  vector_score + bm25_score AS hybrid_score
FROM (
  SELECT id, title,
    embedding <=> query_embedding AS vector_score,
    bm25_rank(content, 'intelligence artificielle') AS bm25_score
  FROM documents
  ORDER BY hybrid_score DESC
  LIMIT 20
);

Ce que cela change architecturalement

Supprimer le sidecar Elasticsearch, c'est :

• Moins de services à opérer : pas de cluster à maintenir, pas de synchronisation des données entre deux systèmes
• Moins de latence : les jointures entre résultats vectoriels et données relationnelles restent dans la même base
• Moins de surface d'erreur : cohérence transactionnelle garantie par PostgreSQL
• Moins de coût : un seul moteur à provisionner

Pour des équipes de taille intermédiaire — comme celles que l'on accompagne chez MulerTech — c'est une simplification opérationnelle significative.

Ce qu'il faut garder en tête

pgvectorscale n'est pas une solution magique. Quelques points de vigilance :

• DiskANN a un recall légèrement inférieur à HNSW en mémoire. Si votre dataset tient confortablement en RAM et que la précision est critique, HNSW reste pertinent.
• L'écosystème Tiger Data est cohérent mais propriétaire dans son orientation. pgvectorscale est open source (Apache 2.0), mais les extensions comme pgai introduisent des dépendances à surveiller.
• BM25 via pg_textsearch est récent. Il faudra valider sa maturité et ses performances selon vos volumes avant de le substituer à Elasticsearch en production.
• Le rebrand Timescale → Tiger Data (juin 2025) signale un pivot stratégique. L'entreprise mise sur une suite d'extensions IA pour PostgreSQL. C'est une direction crédible, mais la consolidation du marché autour de ces outils reste à confirmer.

Conclusion

La combinaison pgvectorscale + pg_textsearch représente une avancée réelle vers l'architecture IA monolithique dans PostgreSQL : une seule base, capable de gérer données relationnelles, recherche sémantique à grande échelle et recherche full-text BM25. Pour des projets PHP/Symfony qui intègrent des fonctionnalités IA, cela ouvre la voie à une stack plus simple, moins coûteuse et plus cohérente.

Ce n'est pas encore le remplacement universel d'Elasticsearch pour tous les cas d'usage — mais pour la majorité des applications web de taille intermédiaire, c'est une piste à explorer sérieusement avant de provisionner un cluster supplémentaire.

📖 Source originale : Christophe Pettus — On pgvectorscale, and Hybrid Search Without an Elasticsearch Sidecar