Qdrant vs Chroma vs pgvector: Eligiendo la base de datos vectorial correcta para RAG autoalojado

Qdrant vs Chroma vs pgvector: Eligiendo la base de datos vectorial correcta para RAG autoalojado

La decisión Qdrant vs Chroma vs pgvector se reduce a un equilibrio de tres vías: velocidad especializada, simplicidad para prototipos, o quedarse dentro del ecosistema de Postgres. Cada enfoque funciona, la pregunta es qué compromiso encaja con tu pipeline RAG.

Resumen rápido: ¿Qué base de datos vectorial deberías elegir?

Elige Qdrant si necesitas búsqueda vectorial de nivel producción con filtrado avanzado, multi-tenencia, y no te importa ejecutar un servicio separado.

Elige Chroma si estás creando prototipos, quieres desarrollo local sin configuración, o necesitas ir de una idea a un RAG funcionando en menos de una hora.

Elige pgvector (+ pgvectorscale) si ya ejecutas PostgreSQL y quieres búsqueda vectorial sin agregar infraestructura, especialmente ahora que el índice StreamingDiskANN de pgvectorscale ha cerrado la brecha de rendimiento.

Si estás construyendo una aplicación RAG desde cero, el resto de este artículo te ayudará a elegir el cimiento correcto.

Rendimiento: ¿Qué tan rápida es cada base de datos?

El rendimiento importa una vez que superas unos pocos miles de documentos. Aquí es donde estos tres divergen significativamente.

Qdrant

Qdrant está construido desde cero para la búsqueda vectorial. Su implementación en Rust y el índice HNSW personalizado entregan latencia consistentemente baja, los benchmarks muestran una latencia de consulta de alrededor de 94 ms incluso bajo carga concurrente. Admite cuantización escalar, binaria y de producto para comprimir vectores y acelerar la búsqueda manteniendo el recall por encima del 95%.

Donde Qdrant realmente brilla es en la búsqueda filtrada. A diferencia de las bases de datos que primero encuentran los vecinos más cercanos y luego filtran, el HNSW filtrable de Qdrant respeta las restricciones de metadatos durante el recorrido del grafo. Eso significa que no pierdes recall al combinar búsqueda vectorial con filtros como category = "technical" o date > 2025-01-01.

Chroma

La versión 1.0 de Chroma reescribió el núcleo en Rust, entregando escrituras y consultas 3-5 veces más rápidas en comparación con la implementación original en Python. Una actualización posterior en agosto de 2025 agregó codificación de vectores en base64 para otro aumento del 70% en rendimiento.

Para conjuntos de datos bajo un millón de vectores, Chroma es genuinamente rápido. Funciona integrado en tu proceso Python sin sobrecarga de red, lo que hace que la iteración local sea ágil. Pero es una base de datos de nodo único, no hay fragmentación ni replicación incorporadas.

pgvector + pgvectorscale

Este es el caballo oscuro. El pgvector estándar con HNSW es 5.250 veces más rápido que un escaneo secuencial, y pgvector 0.8.0 agregó escaneo de índice iterativo para resolver el problema de sobre-filtrado que afectaba versiones anteriores.

Pero la historia real es pgvectorscale. La extensión de Timescale agrega el índice StreamingDiskANN, inspirado en la investigación DiskANN de Microsoft, que almacena el índice en disco en lugar de RAM. En un benchmark de 50 millones de embeddings de Cohere (768 dimensiones), pgvectorscale alcanzó 471 QPS con 99% de recall. Eso es 11,4 veces mayor rendimiento que los 41 QPS de Qdrant en el mismo nivel de recall, y una latencia p95 28 veces menor que el índice optimizado para almacenamiento de Pinecone.

¿El inconveniente? Estos benchmarks utilizaron una instancia EC2 potente. Tus resultados dependen del hardware. Pero la trayectoria es clara: PostgreSQL ya no es la opción "suficientemente buena" para la búsqueda vectorial, es genuinamente competitivo.

Veredicto: pgvector + pgvectorscale gana en números brutos de benchmark. Qdrant gana en rendimiento de búsqueda filtrada. Chroma es suficientemente rápido para prototipos pero no está diseñado para escala.

Configuración y experiencia del desarrollador

¿Qué tan rápido puedes ir de cero a vectores?

Qdrant: Docker y listo

Qdrant necesita su propio contenedor:

docker run -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant

Luego inserta vectores a través de la API REST o uno de los SDK oficiales (Python, Rust, Go, TypeScript):

from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

El dashboard de Qdrant en localhost:6333/dashboard es un buen detalle, puedes explorar colecciones, ejecutar consultas e inspeccionar payloads visualmente. El camino de desarrollo a producción es limpio: tu configuración local de Docker funciona de manera idéntica en un servidor de producción o Qdrant Cloud.

Chroma: pip install y listo

Chroma gana la carrera de simplicidad por un amplio margen:

import chromadb

client = chromadb.Client()  # En memoria, cero configuración
collection = client.create_collection("documents")
collection.add(
    documents=["Tu documento RAG aquí"],
    ids=["doc1"]
)

Sin Docker. Sin servidor. Incluso maneja la generación de embeddings automáticamente si no proporcionas vectores. Para un prototipo RAG, puedes ir de pip install chromadb a una búsqueda funcionando en menos de 10 líneas.

Cuando estés listo para la persistencia, cambia a chromadb.PersistentClient(path="./chroma_data"). Para acceso multiproceso o en red, Chroma tiene un modo servidor, pero en ese punto, comienzas a perder la ventaja de simplicidad.

pgvector: SQL de principio a fin

Si Postgres ya está en tu stack, pgvector es una sola línea:

CREATE EXTENSION vector;

CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

Todo es SQL. Tus embeddings viven junto a los datos de tu aplicación en la misma transacción. Sin pipeline de sincronización, sin credenciales separadas, sin servicio adicional que monitorear. Si ya ejecutas PostgreSQL en producción, este es el camino de menor resistencia.

Agregar pgvectorscale encima es sencillo si usas la imagen Docker de Timescale o un proveedor de Postgres gestionado que lo admita:

CREATE EXTENSION vectorscale;
CREATE INDEX ON documents USING diskann (embedding);

¿El inconveniente? SQL no es tan ergonómico como el DSL de filtrado de payloads de Qdrant o la API Pythónica de Chroma. Y necesitarás gestionar tu propio pipeline de embeddings, pgvector no genera embeddings por ti.

Veredicto: Chroma gana para el prototipo más rápido. pgvector gana si Postgres ya está en tu stack. Qdrant tiene el mejor equilibrio entre experiencia de desarrollador y preparación para producción.

Escalabilidad y preparación para producción

El prototipado es una cosa. Ejecutar un pipeline RAG que maneja millones de vectores con latencia consistente es otra.

Qdrant: Construido para escalar horizontalmente

Qdrant admite fragmentación horizontal de manera nativa. Puedes distribuir colecciones en múltiples nodos, con factores de replicación configurables para alta disponibilidad. Su hoja de ruta para 2026 incluye segregación de lectura-escritura e integración de almacenamiento en bloque para un escalado aún mejor.

La multi-tenencia es una característica de primera clase. Puedes particionar datos por inquilino usando filtrado basado en payload sin crear colecciones separadas, lo que mantiene el uso de recursos eficiente. Para sistemas de memoria de agentes de IA que manejan múltiples usuarios, esta es una ventaja significativa.

La historia operativa es sólida: copias de seguridad integradas, puntos de acceso de métricas para Prometheus, y recuperación de fallos basada en WAL. Qdrant está diseñado para ser autoalojado en producción.

Chroma: Techo de nodo único

Chroma es honesto sobre sus límites. Es una base de datos de nodo único enfocada en simplicidad y desarrollo local. Sin fragmentación integrada, sin replicación, sin clustering.

Chroma Cloud pasó a estar disponible de forma general a principios de 2026 como opción gestionada serverless y distribuida, pero la historia autoalojada es principalmente "un servidor, una instancia de Chroma." Si tu conjunto de datos cabe en una sola máquina (hasta unos pocos millones de vectores dependiendo de la dimensionalidad), está bien. Más allá de eso, te toparás con una pared.

pgvector: Escala con Postgres

pgvector hereda la probada historia de escalado de PostgreSQL. Obtienes réplicas de lectura, agrupación de conexiones a través de PgBouncer, y replicación lógica. Los proveedores gestionados como Neon y plataformas de Postgres serverless similares hacen que el escalado vertical sea casi sin esfuerzo.

El índice StreamingDiskANN de pgvectorscale es la clave para el escalado. Al almacenar el índice del grafo en SSD en lugar de RAM, puedes manejar conjuntos de datos que de otro modo requerirían instancias costosas con mucha memoria. Con 50 millones de vectores, ya es competitivo con bases de datos vectoriales dedicadas.

La limitación es la fragmentación horizontal. PostgreSQL no fragmenta de forma nativa como Qdrant. Existen soluciones como Citus pero agregan complejidad. Para la mayoría de las cargas de trabajo de RAG autoalojado con menos de 100M de vectores, el escalado vertical con pgvectorscale es suficiente.

Veredicto: Qdrant gana para el escalado horizontal y la multi-tenencia. pgvector gana para aprovechar la infraestructura de Postgres existente. Chroma no está diseñado para escala de producción.

Costo del autoalojamiento

Los tres son de código abierto y gratuitos para ejecutar. El costo real es la infraestructura y el tiempo de ingeniería.

pgvector tiene una ventaja de costo estructural: si ya estás pagando por Postgres, agregar búsqueda vectorial es esencialmente gratis hasta que necesites recursos dedicados. Sin contenedor extra, sin monitoreo extra, sin estrategia de copia de seguridad extra.

El uso de recursos de Qdrant es eficiente para su conjunto de funciones, pero es un servicio separado, deberás tener en cuenta la sobrecarga operativa de ejecutar y monitorear otra pieza de infraestructura.

Chroma es el más barato en la etapa de prototipado (cero infraestructura) pero se convierte en el camino más costoso si intentas escalarlo más allá de lo que un solo nodo puede manejar.

Para implementar en plataformas cloud, Qdrant y pgvector tienen implementaciones basadas en Docker sencillas. Chroma también funciona, pero pierdes la simplicidad integrada que es su principal argumento de venta.

Veredicto: pgvector gana en costo total de propiedad (TCO). Elimina un servicio completo de tu stack. Qdrant está razonablemente valorado por lo que ofrece. La historia de costos de Chroma solo funciona durante el prototipado.

Filtrado y búsqueda híbrida

RAG no es solo "encontrar el vector más cercano." Necesitas combinar la búsqueda por similitud con filtros de metadatos, rangos de fechas, controles de acceso, y a veces coincidencia de palabras clave.

Qdrant: El rey del filtrado

El filtrado de payloads de Qdrant ocurre durante el recorrido de HNSW, no después. Esa es una distinción crítica. El post-filtrado puede reducir tu cuenta de resultados por debajo de lo que pediste; el pre-filtrado garantiza que obtengas k resultados que coincidan con tus restricciones.

El DSL de filtrado es expresivo:

from qdrant_client.models import Filter, FieldCondition, MatchValue

results = client.search(
    collection_name="documents",
    query_vector=embedding,
    query_filter=Filter(
        must=[
            FieldCondition(key="category", match=MatchValue(value="engineering")),
            FieldCondition(key="year", range=Range(gte=2024)),
        ]
    ),
    limit=10,
)

Qdrant también admite búsqueda híbrida nativa con vectores densos y dispersos en la misma consulta, lo que es útil para combinar comprensión semántica con precisión de palabras clave.

Chroma: Básico pero utilizable

Chroma admite filtrado de metadatos con cláusulas where:

results = collection.query(
    query_embeddings=[embedding],
    where={"category": "engineering"},
    n_results=10,
)

Funciona para casos simples, pero el filtrado ocurre después de la búsqueda vectorial. Con filtros restrictivos y conjuntos de datos pequeños, podrías obtener menos resultados de los esperados. No hay soporte de vectores dispersos ni búsqueda híbrida integrada.

pgvector: SQL es tu superpoder

pgvector hereda todo el poder de SQL para el filtrado:

SELECT content, embedding <=> $1 AS distance
FROM documents
WHERE category = 'engineering'
  AND created_at > '2024-01-01'
  AND content @@ to_tsquery('RAG & retrieval')
ORDER BY distance
LIMIT 10;

Esa última línea combina similitud vectorial con la búsqueda de texto completo integrada de PostgreSQL en una sola consulta. No se necesita motor de búsqueda externo. Puedes hacer uniones con tu tabla de usuarios para control de acceso, agregar resultados, usar CTEs, todo lo que SQL puede hacer.

El escaneo iterativo de pgvector 0.8.0 también ayuda. Si el escaneo inicial de HNSW no devuelve suficientes resultados filtrados, continúa automáticamente buscando en lugar de devolver un conjunto parcial.

Veredicto: Qdrant gana para filtrado complejo de metadatos a escala. pgvector gana para la flexibilidad de búsqueda híbrida (SQL + texto completo + vector en una consulta). El filtrado de Chroma es adecuado solo para prototipos.

Cuándo usar cada uno: Marco de decisión

Aquí está la versión del árbol de decisión: ¿Tu aplicación ya usa Postgres? Si es así, comienza con pgvector, siempre puedes migrar más tarde si lo necesitas. Si no, ¿estás creando un prototipo o construyendo para producción? Prototipo va hacia Chroma. Producción va hacia Qdrant.

El enfoque "empezar simple, migrar después" es válido porque los tres admiten formatos de embedding estándar. Mover vectores entre ellos es una migración de datos, no una reescritura de arquitectura.

El factor pgvectorscale: Por qué Postgres está alcanzando

Vale la pena detenerse aquí porque cambia el cálculo para muchos equipos.

Antes de pgvectorscale, la crítica a pgvector siempre era "funciona bien bajo un millón de vectores, pero no escala." Eso era verdad. Los índices HNSW viven completamente en RAM, y una vez que tu conjunto de datos supera la memoria disponible, el rendimiento cae en picada.

StreamingDiskANN cambia la ecuación. Al almacenar el índice del grafo en SSD en lugar de RAM, pgvectorscale maneja 50 millones de vectores a 471 QPS con 99% de recall. La Cuantización Binaria Estadística (SBQ) comprime vectores con pérdida mínima de precisión, el recall cae del 98,6% al 96,5% incluso con compresión agresiva.

El impacto práctico: un equipo que ejecuta un pipeline RAG en Postgres ya no necesita planear una migración a una base de datos vectorial dedicada "cuando las cosas se pongan serias." Para muchas cargas de trabajo, pgvector + pgvectorscale es la opción seria.

Dicho esto, pgvectorscale no es una solución mágica. Es una extensión de TigerData (antes Timescale), por lo que necesitas su imagen Docker o un proveedor que la incluya. Una versión de 2026 añadió búsqueda vectorial filtrada por etiquetas a StreamingDiskANN (inspirada en la investigación Filtered DiskANN de Microsoft), lo que reduce la ventaja histórica de Qdrant en consultas filtradas. Pero si necesitas aislamiento multi-inquilino o soporte nativo de vectores dispersos, Qdrant todavía tiene la ventaja.

Cómo Techsy aborda la selección de bases de datos vectoriales

Cuando construimos pipelines RAG para clientes, nuestro proceso de evaluación se ve así:

1. Auditar el stack existente. Si el equipo ya ejecuta Postgres, pgvector es el punto de partida predeterminado. No tiene sentido agregar complejidad de infraestructura a menos que haya una razón clara.
2. Perfilar los patrones de consulta. ¿Filtrado intensivo de metadatos con campos de alta cardinalidad? Eso empuja hacia Qdrant. ¿Búsqueda semántica simple? pgvector o Chroma está bien.
3. Estimar la trayectoria de escala. ¿Bajo 5M de vectores y quedándose ahí? Cualquier opción funciona. ¿Planificando 50M+? pgvectorscale o Qdrant, dependiendo del paso 2.
4. Verificar la capacidad operativa del equipo. Una startup de dos personas no debería gestionar un clúster de Qdrant. Un proveedor de Postgres gestionado con pgvector suele ser la elección correcta.

Hemos construido sistemas RAG de producción con los tres. La respuesta honesta es que la elección de la base de datos importa menos que tu estrategia de fragmentación, el modelo de embedding, y el diseño del pipeline de recuperación. Si estás gastando más tiempo debatiendo Qdrant vs pgvector que probando diferentes tamaños de fragmentos, estás optimizando lo equivocado.

¿Necesitas ayuda diseñando un pipeline RAG? La selección del almacén vectorial y el diseño de la recuperación forman parte de nuestro servicio de integración de IA. Contáctanos y te ayudaremos a elegir la base correcta y construir la capa a su alrededor.

Preguntas frecuentes

¿Es pgvector suficientemente bueno para RAG en producción?

Sí, especialmente con pgvectorscale. El índice StreamingDiskANN maneja 50M+ de vectores con 99% de recall a niveles de rendimiento que superan a las bases de datos vectoriales dedicadas en benchmarks. Si ya ejecutas Postgres, rara vez hay una razón para agregar una base de datos vectorial separada para RAG.

¿Puede Chroma escalar a millones de vectores?

Chroma puede manejar unos pocos millones de vectores en un solo nodo con suficiente RAM, pero no tiene escalado horizontal integrado. Para conjuntos de datos más allá de lo que una sola máquina puede contener, necesitarás migrar a Qdrant, pgvector, o un servicio gestionado.

¿Qdrant admite búsqueda híbrida con palabras clave?

Sí. Qdrant admite vectores densos y dispersos en la misma colección. Puedes ejecutar consultas híbridas que combinen similitud semántica (denso) con coincidencia de palabras clave (disperso) y controlar la ponderación entre ellos.

¿Cuánta RAM necesito para cada base de datos?

Depende del recuento de vectores y las dimensiones. Como guía aproximada: 1M de vectores a 1536 dimensiones toma alrededor de 6 GB en Qdrant o pgvector con HNSW. Chroma usa ligeramente más debido a la sobrecarga de Python. El índice DiskANN de pgvectorscale reduce dramáticamente las necesidades de RAM al almacenar el índice en SSD.

¿Puedo migrar entre estas bases de datos más adelante?

Sí. Las tres funcionan con arrays de float estándar, por lo que los vectores son portables. Necesitarás recrear índices y adaptar tu capa de consulta, pero es una migración de datos, no una reescritura. La mayoría de las herramientas de migración como la herramienta de migración oficial de Qdrant simplifican esto.

¿Cuál funciona mejor con LangChain y LlamaIndex?

Las tres tienen integraciones oficiales con LangChain y LlamaIndex. Chroma es a menudo el predeterminado en tutoriales, lo que lo hace el más fluido para comenzar. Las integraciones de Qdrant y pgvector son igualmente maduras para uso en producción. Consulta nuestra guía sobre las mejores herramientas RAG para una visión más amplia del ecosistema.

¿Debería usar pgvector o pgvectorscale?

Usa ambos. pgvector proporciona el tipo vector central y el índice HNSW. pgvectorscale agrega StreamingDiskANN encima para mejor rendimiento a escala. Son extensiones complementarias, no alternativas.

¿Es Qdrant gratuito para autoalojar?

Completamente gratuito bajo la licencia Apache 2.0. Qdrant Cloud es la opción gestionada de pago, comenzando con un nivel gratuito de 1 GB. Para autoalojamiento, solo pagas por la infraestructura de cómputo.

¿Qué hay de Milvus o Weaviate?

Ambos son alternativas sólidas. Milvus es más fuerte en escala muy grande (mil millones+ de vectores) con aceleración de GPU. Weaviate tiene un buen pipeline de vectorización integrado. Pero para RAG autoalojado con menos de 100M de vectores, Qdrant, Chroma y pgvector cubren la gran mayoría de casos de uso con menos complejidad operativa.

¿Puede pgvector manejar consultas RAG concurrentes en producción?

Sí. PostgreSQL está diseñado para cargas de trabajo concurrentes. pgvector hereda la agrupación de conexiones (PgBouncer), réplicas de lectura, y control de concurrencia MVCC. Para RAG de alto rendimiento, combina pgvector con un agrupador de conexiones y ajusta shared_buffers y effective_cache_size.

Veredicto final

En general: Para la mayoría de los pipelines RAG autoalojados, pgvector + pgvectorscale es la elección pragmática. Es suficientemente rápido, escala a decenas de millones de vectores, y mantiene tu stack simple. Ya conoces SQL. Tu equipo ya gestiona Postgres. Un servicio menos significa una cosa menos que puede romperse a las 2 de la mañana.

Si necesitas búsqueda filtrada avanzada, multi-tenencia, o estás construyendo un producto donde la búsqueda vectorial es la característica central (no una capacidad de apoyo), Qdrant es la inversión correcta. Es la base de datos vectorial de código abierto más completa por una razón.

Chroma se gana su lugar como herramienta de prototipado. Úsala para validar tu enfoque RAG, probar diferentes estrategias de fragmentación e iterar sobre la calidad de recuperación. Cuando estés listo para producción, migra a cualquiera de los otros dos que se ajuste a tu stack.

¿El mejor consejo? Deja de debatir y empieza a construir. Elige pgvector si tienes Postgres, Qdrant si no, y pon tu pipeline RAG a funcionar. Siempre puedes cambiar el almacén vectorial más tarde, el modelo de embedding, la estrategia de fragmentación y la lógica de recuperación importan mucho más.

Fuentes

• Qdrant Benchmarks
• Chroma 1.0 Release: 4x Faster
• pgvectorscale: StreamingDiskANN for PostgreSQL
• pgvector Is Now Faster than Pinecone at 75% Less Cost
• pgvector 0.8.0: Iterative Index Scanning
• Qdrant Pricing