Accueil › Glossaire › ChromaDB

ChromaDB

ChromaDB (Chroma) est une base de données vectorielle open source (licence Apache 2.0) conçue pour stocker, gérer et rechercher des embeddings avec une API simple, un mode embedded (en mémoire dans votre processus Python) et une intégration native avec les frameworks RAG comme LangChain et LlamaIndex.

ChromaDB a conquis la communauté IA par sa simplicité : trois lignes de Python suffisent pour créer une collection, ajouter des documents et lancer une recherche sémantique. C’est le point d’entrée le plus rapide dans le monde des vector stores, parfait pour le prototypage, les tutoriels et les petites applications. Avec le lancement de Chroma Cloud (service managé serverless) et une réécriture du cœur en Rust, ChromaDB évolue vers la production à plus grande échelle.

Pourquoi ChromaDB est si populaire

Simplicité extrême

ChromaDB est le vector store avec la plus faible barrière d’entrée du marché. Vous installez avec pip install chromadb, vous créez un client en mémoire, et vous êtes opérationnel en 30 secondes. Pas de Docker, pas de serveur externe, pas de configuration. Pour les développeurs qui découvrent les embeddings et le RAG, c’est le terrain d’apprentissage idéal.

Embedding automatique

Par défaut, ChromaDB génère les embeddings automatiquement quand vous ajoutez des documents texte. Le modèle par défaut est all-MiniLM-L6-v2 (Sentence Transformers), mais vous pouvez configurer n’importe quel modèle d’embedding : OpenAI, Cohere, Hugging Face, Google, ou vos propres embeddings pré-calculés. Vous envoyez du texte, ChromaDB le transforme en vecteur et le stocke. C’est le flow le plus simple possible.

Intégrations natives

ChromaDB est le vector store le plus intégré avec l’écosystème RAG. LangChain et LlamaIndex le supportent nativement comme backend vectoriel. Les tutoriels, cours et guides RAG les plus populaires utilisent ChromaDB comme exemple. Cette omniprésence dans l’écosystème éducatif a fait de Chroma le vector store le plus connu des développeurs IA.

Fonctionnalités

Types de recherche

Recherche vectorielle : la fonctionnalité de base. Trouvez les documents dont les embeddings sont les plus proches de l’embedding de la requête. Métriques supportées : cosine similarity, distance euclidienne (L2), produit scalaire (inner product).

Full-text search : recherche par mots-clés (BM25) en parallèle de la recherche vectorielle. Ajouté récemment, cela permet une recherche hybride rudimentaire directement dans ChromaDB.

Regex search : recherche par expressions régulières sur les documents stockés. Utile pour trouver des patterns spécifiques (numéros de référence, formats de date, identifiants).

Filtrage par métadonnées : chaque document peut porter des métadonnées (key-value pairs). Les requêtes peuvent filtrer par métadonnées avant la recherche vectorielle. Par exemple, chercher uniquement dans les documents de catégorie « technique » ou publiés après une certaine date.

Collections

Les données dans ChromaDB sont organisées en collections (l’équivalent de tables). Chaque collection a son propre espace d’embeddings et ses propres métadonnées. Vous pouvez créer, lister, récupérer et supprimer des collections. Chaque document dans une collection est identifié par un ID unique.

Modes de stockage

In-memory (éphémère) : chromadb.Client() crée une base en mémoire qui disparaît quand le processus s’arrête. Parfait pour les tests et le prototypage.

Persistant (local) : chromadb.PersistentClient(path="./chroma_db") sauvegarde les données sur disque. Les données survivent aux redémarrages.

Client/Server : chromadb.HttpClient(host="localhost", port=8000) se connecte à un serveur ChromaDB distant, déployé via Docker. Permet le multi-client et les déploiements de petite production.

Chroma Cloud : service managé serverless lancé par l’équipe Chroma. Index construits et optimisés pour le stockage objet (S3/GCS) avec un tiering automatique (mémoire chaude → SSD → stockage froid). Offre 5 $ de crédits gratuits pour démarrer.

Utilisation concrète

import chromadb

# 1. Créer un client persistant
client = chromadb.PersistentClient(path="./chroma_db")

# 2. Créer une collection (embedding automatique par défaut)
collection = client.get_or_create_collection(
    name="documentation",
    metadata={"hnsw:space": "cosine"}  # Métrique de distance
)

# 3. Ajouter des documents (embedding automatique)
collection.add(
    documents=[
        "Pour configurer le firewall, accédez aux paramètres réseau.",
        "La politique de congés prévoit 25 jours par an.",
        "Le déploiement se fait via Docker Compose.",
        "Les tickets support doivent être créés dans Jira.",
    ],
    metadatas=[
        {"category": "technique", "section": "réseau"},
        {"category": "rh", "section": "congés"},
        {"category": "technique", "section": "déploiement"},
        {"category": "support", "section": "processus"},
    ],
    ids=["doc1", "doc2", "doc3", "doc4"]
)

# 4. Recherche sémantique
results = collection.query(
    query_texts=["comment déployer l'application"],
    n_results=2
)
print(results["documents"])
# [['Le déploiement se fait via Docker Compose.',
#   'Pour configurer le firewall, accédez aux paramètres réseau.']]

# 5. Recherche avec filtrage par métadonnées
results = collection.query(
    query_texts=["processus interne"],
    n_results=2,
    where={"category": "technique"}  # Seulement les docs techniques
)

# 6. Mettre à jour un document
collection.update(
    ids=["doc1"],
    documents=["Pour configurer le firewall v2, voir le guide réseau."],
    metadatas=[{"category": "technique", "section": "réseau", "version": "2.0"}]
)

# 7. Supprimer un document
collection.delete(ids=["doc4"])

# Utilisation avec un modèle d'embedding custom (OpenAI)
import chromadb
from chromadb.utils.embedding_functions import OpenAIEmbeddingFunction

embedding_fn = OpenAIEmbeddingFunction(
    api_key="YOUR_OPENAI_KEY",
    model_name="text-embedding-3-small"
)

collection = client.get_or_create_collection(
    name="docs_openai",
    embedding_function=embedding_fn
)

# Les documents seront embedés avec OpenAI au lieu du modèle par défaut
collection.add(
    documents=["Votre texte ici..."],
    ids=["id1"]
)

# Intégration avec LangChain pour un pipeline RAG
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.chains import RetrievalQA

# Créer un vector store LangChain avec ChromaDB
vectorstore = Chroma.from_documents(
    documents=split_docs,  # Documents pré-chunkés
    embedding=OpenAIEmbeddings(),
    persist_directory="./chroma_langchain"
)

# Créer un pipeline RAG
qa_chain = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-4o"),
    retriever=vectorstore.as_retriever(search_kwargs={"k": 5}),
    return_source_documents=True
)

result = qa_chain.invoke({"query": "Comment configurer le firewall ?"})

Chroma Cloud

Chroma Cloud est le service managé serverless lancé par l’équipe Chroma. Il adresse la principale limitation historique de ChromaDB : le passage à la production. L’architecture repose sur trois niveaux de stockage :

Cache mémoire (hot) : les données fréquemment accédées sont en RAM pour des latences minimales.

Cache SSD (warm) : les données intermédiaires sont sur SSD pour un bon compromis latence/coût.

Stockage objet (cold) : toutes les données (vecteurs, métadonnées, index) sont persistées sur S3/GCS. Le tiering est automatique et transparent.

Le moteur a été réécrit en Rust (push-based, morsel-driven execution engine), ce qui élimine les limitations du Global Interpreter Lock de Python et offre des gains de performance de 4x sur les écritures et les requêtes. ChromaDB Cloud supporte désormais la recherche vectorielle, le full-text search (BM25 et SPLADE), et la recherche par regex.

Le pricing est basé sur l’usage avec 5 $ de crédits gratuits pour démarrer. Des clusters dédiés sont disponibles sur devis pour les workloads enterprise.

Forces et limites

Points forts

Démarrage instantané. pip install chromadb et vous êtes opérationnel. Pas de Docker, pas de serveur, pas de configuration. C’est le vector store le plus rapide à essayer.

Embedding automatique. Envoyez du texte brut, ChromaDB génère les embeddings pour vous. Vous pouvez aussi fournir vos propres vecteurs. La flexibilité est totale.

Écosystème éducatif massif. La quasi-totalité des tutoriels RAG, cours et guides utilisent ChromaDB comme exemple. Trouver de l’aide est facile, la documentation est claire, et les exemples de code abondent.

Open source (Apache 2.0). Pas de restriction de licence. Vous pouvez l’utiliser dans des projets commerciaux, le modifier et le redistribuer.

Évolution vers la production. La réécriture en Rust et le lancement de Chroma Cloud montrent que l’équipe investit sérieusement dans la scalabilité. ChromaDB n’est plus uniquement un outil de prototypage.

Limites

Historiquement limité en scale. Le mode embedded (in-memory) atteint ses limites au-delà de quelques centaines de milliers de vecteurs. La mémoire consommée par les opérations vectorielles augmente rapidement avec le volume. Pour les millions de vecteurs, Qdrant, Milvus ou pgvector sont plus adaptés.

Pas de multi-tenancy native. Contrairement à Weaviate, ChromaDB ne propose pas d’isolation par tenant intégrée. Pour isoler les données de différents clients, vous devez créer des collections séparées ou gérer l’isolation au niveau applicatif.

Hybrid search moins mature. Le support BM25 et SPLADE est récent et moins intégré que chez Weaviate (BM25 natif depuis des années) ou Pinecone (sparse vectors matures). Pour les applications où la recherche hybride est critique, les alternatives sont plus robustes.

Pas de RBAC intégré. ChromaDB (self-hosted) ne propose pas de contrôle d’accès granulaire. Pour les environnements multi-utilisateurs avec des exigences de sécurité, c’est une limitation. Chroma Cloud ajoute des fonctionnalités de sécurité, mais elles sont encore en développement.

Mode client/server basique. Le mode client/server (via Docker) fonctionne sur un seul nœud. Il n’y a pas de sharding natif ni de réplication pour la haute disponibilité en self-hosted. Chroma Cloud comble cette lacune avec une architecture distribuée.

Cas d’usage concrets

Chatbot sur documentation interne

Le cas d’usage le plus fréquent. Une équipe charge la documentation technique de son produit (markdown, PDF, pages Notion) dans ChromaDB via LangChain. Un chatbot interne permet aux développeurs de poser des questions en langage naturel et d’obtenir des réponses basées sur la documentation. ChromaDB gère le stockage des chunks embedés et le retrieval. Le LLM (GPT-4o, Claude) génère la réponse à partir du contexte récupéré. Pour une documentation de quelques milliers de pages, ChromaDB en mode persistant est parfaitement suffisant.

Recherche sémantique dans une application

Un SaaS de gestion de tickets de support indexe les résolutions passées dans ChromaDB. Quand un nouvel ticket arrive, le système cherche les tickets similaires déjà résolus et propose des solutions potentielles à l’agent support. Le filtrage par métadonnées (produit, catégorie, priorité) restreint la recherche aux tickets pertinents. Pour quelques dizaines de milliers de tickets, ChromaDB offre des performances largement suffisantes.

Prototypage rapide d’un pipeline RAG

Un data scientist explore l’idée d’augmenter un LLM avec des données propriétaires. Avant d’investir dans une infrastructure Pinecone ou Qdrant, il construit un prototype en 30 minutes avec ChromaDB embedded, valide la qualité du retrieval sur un jeu de test, mesure le recall@5, et présente les résultats à son équipe. Si le prototype convainc, la migration vers un vector store de production se fait ensuite avec les données déjà préparées.

Apprentissage et formation

ChromaDB est utilisé dans la majorité des cours en ligne sur le RAG (DataCamp, DeepLearning.AI, Coursera, tutoriels YouTube). Sa simplicité permet aux étudiants de se concentrer sur les concepts (embeddings, similarité, chunking) plutôt que sur la configuration d’infrastructure. C’est le « Jupyter Notebook des vector stores » : pas conçu pour la production, mais indispensable pour l’apprentissage.

Architecture technique

L’architecture de ChromaDB a évolué significativement avec la réécriture en Rust :

Moteur d’exécution Rust. Le cœur de ChromaDB a été réécrit en Rust avec un moteur d’exécution push-based et morsel-driven. Cette architecture élimine le Global Interpreter Lock (GIL) de Python qui limitait le parallélisme, offrant un vrai multithreading et des performances multipliées par 4 sur les opérations de lecture et d’écriture.

Index vectoriel HNSW. ChromaDB utilise HNSW (Hierarchical Navigable Small World) pour l’indexation vectorielle, l’algorithme le plus performant pour la recherche ANN (Approximate Nearest Neighbor). Les paramètres d’indexation (ef_construction, M) sont configurables par collection pour ajuster le compromis recall/latence.

Format Apache Arrow. Les données sont stockées en format Apache Arrow pour un accès rapide en mémoire. Arrow est un format columnar in-memory qui permet des opérations vectorielles efficaces sans sérialisation/désérialisation coûteuse.

Stockage tiéré (Cloud). Chroma Cloud implémente un stockage en trois niveaux : cache RAM pour les requêtes fréquentes, cache SSD pour les données tièdes, et stockage objet (S3/GCS) pour la persistance froide. Le tiering est automatique et optimisé par les patterns de requêtes, sans configuration manuelle.

ChromaDB vs alternatives

Quand et comment migrer depuis ChromaDB

ChromaDB est souvent le premier vector store qu’une équipe utilise. La question n’est pas « si » mais « quand » migrer vers une solution plus robuste. Les signaux qui indiquent qu’il est temps de migrer :

Volume : vos collections dépassent quelques centaines de milliers de vecteurs et les performances se dégradent.

Concurrence : plusieurs processus ou utilisateurs accèdent simultanément aux données et vous rencontrez des problèmes de locking.

Haute disponibilité : votre application ne peut pas tolérer d’interruption, et vous avez besoin de réplication et de failover.

Sécurité : vous avez besoin de RBAC, de chiffrement at-rest, ou de conformité (SOC 2, HIPAA).

La migration est relativement simple : exportez vos documents et embeddings depuis ChromaDB (via l’API get()), et réindexez-les dans le nouveau vector store. Si vous avez utilisé un modèle d’embedding identique, les vecteurs sont directement réutilisables. La plupart des équipes migrent vers pgvector (si elles ont PostgreSQL), Qdrant (si elles veulent du self-hosted performant) ou Pinecone (si elles veulent du managé).

Verdict

ChromaDB est le « Hello World » des vector stores. Sa simplicité en fait le meilleur point de départ pour apprendre les concepts d’embeddings, de recherche sémantique et de RAG. Pour un prototype ou un MVP, c’est suffisant et vous permet d’itérer rapidement sans surcharge d’infrastructure.

L’évolution de ChromaDB est encourageante : la réécriture en Rust, le support du full-text search et la regex search, et le lancement de Chroma Cloud montrent une ambition de production sérieuse. Mais pour les applications en production avec des exigences de scale, de performance, de sécurité ou de haute disponibilité, les alternatives (pgvector, Qdrant, Pinecone, Weaviate) sont plus matures et éprouvées.

La stratégie recommandée : commencez avec ChromaDB pour valider votre concept RAG. Conservez vos textes sources et utilisez un modèle d’embedding standard. Quand les limites de ChromaDB apparaissent, migrez vers l’outil adapté à vos besoins de production. La migration est un export + réindexation, pas une réécriture complète.