Vous avez construit un système RAG. Les documents entrent, les embeddings sont créés, la recherche de similarité renvoie des morceaux pertinents. Ça fonctionne. Puis votre jeu de données passe de 100 documents à 100 000. La latence de recherche explose de 200 ms à 8 secondes. L’instance Chroma que vous avez lancée sur votre ordinateur portable ne peut pas évoluer. Maintenant, vous vous demandez : ai-je vraiment besoin d’une base de données vectorielle dédiée, ou est-ce un argumentaire de vente ?
Ce que fait réellement une base de données vectorielle
Séparez le battage médiatique de la fonction. Une base de données vectorielle est un système spécialisé optimisé pour une seule tâche : stocker des vecteurs de haute dimension (embeddings) et renvoyer les k vecteurs les plus similaires à une requête en moins d’une seconde. C’est tout. Pas de transactions. Pas de jointures complexes. Pas de garanties ACID. Juste une recherche rapide du plus proche voisin à l’échelle.
Les bases de données relationnelles standard peuvent stocker des vecteurs. PostgreSQL a l’extension pgvector. Ça fonctionne. Mais « fonctionner » et « fonctionner bien à l’échelle » sont deux choses différentes. Une requête PostgreSQL analysant 10 millions de vecteurs d’embedding avec une similarité cosinus par force brute prendra 2 à 5 secondes. Une base de données vectorielle sur le même jeu de données renvoie les résultats en 50 à 200 ms. La différence est algorithmique — les bases de données vectorielles utilisent des structures d’index (HNSW, IVF, DiskANN) conçues spécifiquement pour la recherche approximative du plus proche voisin, pas la correspondance exacte.
Traduction : si vous avez moins de 50 000 embeddings et qu’une latence inférieure à 500 ms est acceptable, vous n’en avez pas besoin. Si vous avez des millions de vecteurs, du trafic de production et des utilisateurs qui attendent des résultats de recherche, vous en avez besoin.
Pinecone vs Weaviate vs ChromaDB : Les vrais compromis
Pinecone : Sans serveur, entièrement géré, uniquement dans le cloud. Vous envoyez des vecteurs via API. Pinecone gère la mise à l’échelle, la réplication, les sauvegardes. Zéro infrastructure. Coût : 0,25 $–1,50 $ par 1 million de vecteurs par mois, plus 0,04 $ par 1K requêtes. Idéal pour : les équipes qui ne veulent pas gérer de bases de données. Limites : dépendance vis-à-vis du fournisseur, pas de version de développement locale, plus lent que les alternatives auto-hébergées en raison de la latence réseau.
Weaviate : Open-source, auto-hébergé ou version cloud gérée. Vous exécutez la base de données (sur vos serveurs ou Weaviate Cloud). Contrôle total du déploiement, de la résidence des données, de la mise à l’échelle. Prise en charge intégrée de la recherche hybride (filtrage par vecteur + mot-clé). Mieux pour : les équipes ayant des exigences de conformité spécifiques, une préférence pour l’open-source, ou une infrastructure Kubernetes existante. Compromis : vous gérez vous-même les mises à niveau, les sauvegardes et la mise à l’échelle. La latence est plus faible que Pinecone car les requêtes ne traversent pas Internet.
ChromaDB : Léger, open-source, conçu pour le prototypage. S’exécute en processus (pas de serveur) ou en tant que service autonome. Stocke les données localement ou dans le stockage cloud. Idéal pour : l’expérimentation, les petits jeux de données (moins de 100k vecteurs), les environnements de développement. Pas prêt pour la production à grande échelle — la latence se dégrade rapidement au-delà de 500k vecteurs, et le support des requêtes distribuées est limité.
Chiffres réels : dans un test de référence avec 1 million d’embeddings OpenAI (1536 dimensions), Pinecone a renvoyé des résultats en ~120 ms, Weaviate auto-hébergé en ~80 ms, ChromaDB en ~600 ms. La latence réseau vers l’API Pinecone ajoute 50 à 100 ms selon la géographie. Cela compte lorsque vous effectuez plusieurs requêtes par demande utilisateur.
Quand vous avez absolument besoin d’une base de données vectorielle
Trois scénarios :
- Pression sur l’échelle + latence : Plus de 100k embeddings + recherche utilisateur qui doit s’achever en moins de 500 ms. PostgreSQL + pgvector fonctionnera, mais pas rapidement.
- Recherche hybride : Vous devez filtrer les vecteurs par métadonnées avant la recherche de similarité (« trouver des documents similaires à X, mais uniquement à partir de 2024 »). Les bases de données vectorielles ont un filtrage natif. Faire cela dans PostgreSQL nécessite une clause WHERE distincte qui annule l’optimisation de l’index.
- Mises à jour en temps réel : Vous ajoutez/supprimez constamment des documents. Pinecone et Weaviate prennent en charge les upserts sans ré-indexation complète. La reconstruction des index ChromaDB ou PostgreSQL devient coûteuse à grande échelle.
Une configuration pratique : Quand utiliser quoi
Commencez avec ChromaDB si votre jeu de données est inférieur à 10 000 documents et que la latence n’est pas une contrainte. Déployez-le en processus, stockez les vecteurs en JSON, avancez. Vous dépenserez 0 € en infrastructure et saurez immédiatement si la recherche vectorielle résout votre problème.
Passez à Pinecone lorsque vous atteignez l’un de ces obstacles : vous avez besoin d’une latence inférieure à 200 ms, votre jeu de données dépasse 100 000 vecteurs, ou vous ne voulez pas gérer l’infrastructure. Les 0,04 € par 1K requêtes s’accumulent à grande échelle, mais vous payez pour la vitesse et la fiabilité gérée. Pas de réglage d’index, pas de planification de capacité.
Choisissez Weaviate si vous utilisez déjà Kubernetes, si vous devez héberger des vecteurs dans votre propre compte cloud, ou si vous avez besoin d’une logique de recherche hybride personnalisée. Vous échangez la commodité contre le contrôle. La configuration prend une semaine. La mise à l’échelle nécessite de la maintenance. Mais vous possédez les données et la latence est meilleure.
La réalité du code : stockage des embeddings
Voici à quoi ressemble un flux de travail de base d’embedding + recherche dans ChromaDB (développement) vs Pinecone (échelle de production) :
# ChromaDB : Simple, en processus
import chromadb
from chromadb.utils import embedding_functions
client = chromadb.Client()
openai_ef = embedding_functions.OpenAIEmbeddingFunction(
api_key="votre-clé",
model_name="text-embedding-3-small"
)
collection = client.get_or_create_collection(
name="docs",
embedding_function=openai_ef
)
# Ajouter des documents
collection.add(
ids=["doc1", "doc2"],
documents=["Contenu A", "Contenu B"]
)
# Rechercher
results = collection.query(
query_texts=["Trouver du contenu similaire"],
n_results=3
)
print(results['documents'][0])# Pinecone : Évolutif, basé sur API
import pinecone
from openai import OpenAI
pinecone.init(api_key="votre-clé", environment="us-west-2-aws")
index = pinecone.Index("production-index")
client = OpenAI(api_key="votre-clé")
# Embed et stocker
docs = ["Contenu A", "Contenu B"]
embeddings = [
client.embeddings.create(
input=doc,
model="text-embedding-3-small"
).data[0].embedding
for doc in docs
]
# Upsert (mettre à jour ou insérer)
vectors = [
("doc1", embeddings[0], {"text": docs[0]}),
("doc2", embeddings[1], {"text": docs[1]})
]
index.upsert(vectors=vectors)
# Rechercher
query_embedding = client.embeddings.create(
input="Trouver du contenu similaire",
model="text-embedding-3-small"
).data[0].embedding
results = index.query(
vector=query_embedding,
top_k=3,
include_metadata=True
)
for match in results['matches']:
print(match['metadata']['text'])
La version Chroma a 8 lignes. Pinecone nécessite des clés API, des embeddings calculés séparément et des métadonnées structurées. Mais Pinecone peut gérer des millions de vecteurs sans dégradation. Chroma ralentit visiblement au-delà de 500k.
Faites ceci aujourd’hui : testez votre limite d’échelle
Avant de choisir une base de données, exécutez ChromaDB avec votre nombre réel de documents. Mesurez la latence des requêtes à 10k vecteurs, 100k et 1 million (si possible). Définissez un seuil de latence — peut-être 300 ms est acceptable pour vos utilisateurs, peut-être pas. Si ChromaDB atteint ce seuil avant que vos données n’atteignent 500k vecteurs, vous avez une réponse. Si elle évolue bien pour la taille prévue de votre jeu de données, restez local. L’argent que vous économisez sur l’infrastructure bat les fonctionnalités du fournisseur dont vous n’avez pas besoin.
