Base vectorielle (pgvector, Atlas, Pinecone)

IA / LLM 🟡 Mid

Définition

Stockage et recherche de vecteurs par plus proches voisins, exacts ou approximatifs (index HNSW, IVFFlat). pgvector 0.8.6 ajoute à PostgreSQL les types vector, halfvec, sparsevec (jusqu'à 16 000 dimensions) et les opérateurs <-> (L2), <=> (cosinus), <#> (produit scalaire négatif). MongoDB Atlas Vector Search expose l'étape $vectorSearch (ANN via HNSW ou ENN exact, 8 192 dimensions max). Pinecone est un service managé dédié.

Analogie

Un index de bibliothèque classé par « voisinage de sens » plutôt que par ordre alphabétique.

Exemple de code

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id bigserial PRIMARY KEY,
  url text, content text,
  embedding vector(1536)                -- text-embedding-3-small
);
-- Index approximatif HNSW, distance cosinus
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

-- Top 5 voisins de la question ($1 = vecteur JSON '[0.01,...]')
SELECT url, content, 1 - (embedding <=> $1::vector) AS score
FROM chunks
ORDER BY embedding <=> $1::vector
LIMIT 5;

Cas d'usage

RAG sur une stack déjà PostgreSQL ou MongoDB sans ajouter d'infrastructure ; Pinecone quand le volume ou la charge le justifie.

Anti-pattern

Créer l'index HNSW sur une table vide puis charger des millions de lignes : construire l'index après le chargement.

Termes liés

#ia#rag#postgresql#mongodb#interview

En entretien

Explique-moi la différence entre pgvector, MongoDB Atlas Vector Search et Pinecone.
pgvector ajoute des types vecteur et des opérateurs de distance directement à PostgreSQL, Atlas expose une étape $vectorSearch dans MongoDB, alors que Pinecone est un service managé dédié. Le choix dépend surtout de la stack déjà en place : pas besoin d'ajouter une brique si Postgres ou Mongo sont déjà là.
Quand est-ce que tu éviterais pgvector au profit de Pinecone ?
Quand le volume ou la charge de recherche vectorielle justifie un service dédié et managé plutôt que de faire cohabiter ça avec la base relationnelle existante. Sinon pgvector suffit et évite d'ajouter de l'infrastructure.
Comment tu debuggerais une recherche vectorielle lente sur des millions de lignes ?
Je vérifierais si l'index HNSW a été construit après le chargement des données plutôt qu'avant sur une table vide, car c'est l'anti-pattern classique qui casse les performances. Créer l'index une fois les données chargées est la bonne pratique.

Sources

Fiche mise à jour le 2026-09-27