Chroma: una base vectorial ligera para prototipos con embeddings

Chroma^[1] es probablemente la base de datos vectorial más sencilla de adoptar. Si construyes un primer prototipo de búsqueda semántica o un sistema de Retrieval-Augmented Generation (RAG), Chroma permite empezar en minutos sin desplegar infraestructura adicional.

El proyecto es de código abierto bajo licencia Apache 2.0 y acumula más de 28.000 estrellas en su repositorio de GitHub^[2]. Va ya por la versión 1.5.x, con el núcleo reescrito en Rust para mejorar el rendimiento. Cubrimos cuándo es la opción correcta, cuándo conviene migrar a algo más serio, y los patrones de uso más comunes.

Puntos clave

• pip install chromadb y tienes una BD embebida que persiste a disco, sin infraestructura adicional.

• API mínima: add, query, delete. Generación de embeddings integrada por defecto con sentence-transformers.

• Integración nativa con LangChain y LlamaIndex como retriever sustituible.

• Límite práctico: corpus de unos pocos millones de vectores; por encima, Qdrant o Milvus escalan mejor.

• Señal de migración: latencia >200 ms en queries o necesidad de búsqueda híbrida avanzada.

El problema que resuelve

Una base de datos vectorial indexa vectores numéricos (embeddings) y permite buscar los más similares a un vector de consulta usando distancias como coseno o euclídea. Es el componente clave de cualquier sistema RAG: dado un texto de pregunta, encontrar los fragmentos más relacionados en un corpus.

En el ecosistema actual compiten Pinecone (gestionada), Qdrant, Weaviate, Milvus y pgvector, entre otras. Cada una optimiza distintos puntos del trade-off entre rendimiento, escalabilidad, funcionalidades y simplicidad. Chroma se posiciona claramente del lado de la simplicidad.

Por qué Chroma destaca para prototipar

• Cero infraestructura para arrancar. pip install chromadb y ya tienes una BD embebida que persiste a disco.

• API mínima y consistente. add, query, delete. No hay 20 conceptos a aprender.

• Generación de embeddings integrada. Por defecto usa el modelo all-MiniLM-L6-v2 de Sentence Transformers para vectorizar texto; soporta OpenAI Embeddings o cualquier función personalizada.

• Integración nativa con LangChain y LlamaIndex. Plug-and-play para los frameworks RAG dominantes.

• Modos de despliegue gradual. Empieza embebido, escala a cliente-servidor con chroma run, eventualmente a producción.

Esto la hace ideal para validar una idea o construir una primera versión sin bloquearte en decisiones de infraestructura.

Un ejemplo mínimo

import chromadb

client = chromadb.Client()
collection = client.create_collection(name="docs")

collection.add(
    documents=["El kernel de Linux acepta Rust desde 6.1",
               "OpenTofu es el fork comunitario de Terraform"],
    metadatas=[{"tag": "kernel"}, {"tag": "iac"}],
    ids=["d1", "d2"],
)

results = collection.query(
    query_texts=["Quiero saber sobre infraestructura como código"],
    n_results=1,
)
print(results)

Sin configurar embeddings explícitamente, Chroma genera un vector con su modelo por defecto y devuelve el documento más cercano semánticamente. Una funcionalidad similar en otras bases vectoriales requiere más código para arrancar.

Limitaciones que conviene conocer

Chroma es excelente para empezar; es honesta sobre dónde no es la mejor opción:

• Escala limitada. Su arquitectura no está diseñada para cientos de millones de vectores. Si el corpus supera unos cuantos millones, Qdrant o Milvus escalan mejor.

• Filtros por metadatos básicos. No hay indexado avanzado al estilo de Weaviate para filtros complejos.

• Sin replicación nativa. La versión cliente-servidor corre como proceso único. Para alta disponibilidad necesitas envolver con tu propia capa.

• Performance bajo carga concurrente alta. Está optimizado para uso típico de prototipo o RAG de tamaño medio, no para QPS altos sostenidos.

Si tu caso de uso requiere alguno de estos puntos, no es la herramienta. Si tu caso es "necesito buscar entre 100.000 documentos para un asistente RAG interno", probablemente sea perfecta.

Patrones comunes de RAG con Chroma

La estructura típica que aparece en proyectos:

• Ingestión. Cargar documentos (PDF, markdown, web), partirlos en chunks de 200-1000 tokens, generar embeddings, guardar en Chroma con metadatos (fuente, fecha, autor).

• Consulta. Recibir pregunta, generar su embedding, buscar top-k chunks más similares (k=3-5 en la práctica).

• Composición de prompt. Construir un prompt para el LLM con la pregunta + contexto recuperado + instrucciones.

• Respuesta. El LLM responde basándose en el contexto, citando fuentes si corresponde.

Frameworks como LangChain encapsulan este flujo en pocas líneas, con Chroma como retriever sustituible por cualquier otra BD vectorial cuando crezcas; la propia documentación de integración de LangChain^[3] lo describe así. Para entender en profundidad qué modelos de embedding elegir antes de indexar, ver el artículo sobre embeddings de texto aplicados.

Cuándo migrar a otra cosa

Señales claras de que has superado a Chroma:

• Latencia consistentemente alta (>200 ms) en queries.

• Memoria del proceso saturándose durante búsquedas grandes.

• Necesidad de búsqueda híbrida (vectorial + keyword + filtros) para mejorar relevancia: aquí destaca Weaviate.

• Múltiples instancias servidor sin replicación nativa.

• Compliance que exige BD gestionada con SLA: terreno de Pinecone y otras opciones totalmente gestionadas.

La migración suele ser razonable porque tu lógica de RAG queda casi igual: cambias la implementación del retriever, no el resto del pipeline. Por eso conviene estructurar el código con esa abstracción desde el principio, que es exactamente lo que hacen los wrappers de LangChain.

Conclusión

Chroma es la elección por defecto para empezar con embeddings, especialmente si construyes un primer RAG o experimento. Su simplicidad acelera la fase de exploración cuando no quieres bloquearte en infraestructura. Cuando el proyecto crezca y aparezcan necesidades de escalado, replicación o búsqueda avanzada, hay opciones más maduras a las que migrar. Esa migración, eso sí, llegará después de haber validado el concepto, no antes.

Este artículo también está disponible en inglés: Chroma: A Lightweight Vector Database for Embedding Prototypes.

Fuentes:

1. Chroma — Documentación oficial^[4]
2. chroma-core/chroma — Repositorio en GitHub^[2]
3. LangChain — Integración con Chroma como vector store^[3]

Preguntas frecuentes

¿Necesito configurar un modelo de embeddings para empezar con Chroma?

No. Tras pip install chromadb tienes una base embebida que persiste a disco y, sin configurar embeddings, Chroma vectoriza el texto con el modelo all-MiniLM-L6-v2 de Sentence Transformers por defecto. Si lo prefieres, soporta OpenAI Embeddings o cualquier función personalizada. La API se reduce a add, query y delete, y se integra de forma nativa con LangChain y LlamaIndex como retriever sustituible.

¿Hasta cuántos vectores aguanta Chroma antes de que convenga migrar?

El límite práctico está en un corpus de unos pocos millones de vectores; por encima, Qdrant o Milvus escalan mejor. Las señales de que la has superado son latencia consistentemente alta (más de 200 ms) en queries y memoria del proceso saturándose en búsquedas grandes. También la necesidad de búsqueda híbrida vectorial más keyword más filtros, más de una instancia servidor sin replicación nativa o compliance que exija una BD gestionada con SLA.

¿Puedo usar Chroma en producción con alta disponibilidad?

Con reservas. La versión cliente-servidor, que se arranca con chroma run, corre como proceso único y no tiene replicación nativa, así que para alta disponibilidad necesitas envolverla con tu propia capa. Además los filtros por metadatos son básicos y el rendimiento está optimizado para prototipos o RAG de tamaño medio, no para QPS altos sostenidos. Para buscar entre 100.000 documentos de un asistente RAG interno probablemente sea perfecta.

Fuentes

1. Chroma
2. repositorio de GitHub
3. documentación de integración de LangChain
4. Chroma — Documentación oficial