Comparativa Vector DB

Qué incluye este pack

Este pack pone las siete opciones dominantes de bases de datos vectoriales lado a lado para que la decisión sea ejercicio de 10 minutos en vez de evaluación de una semana. El espacio de elección se divide limpio en tres niveles: bases auto-alojadas, gestionadas, y APIs de embedding (que suelen incluir un store vectorial básico de paso).

Este pack es intencionalmente la capa DB — qué guarda los vectores y sirve queries de vecino más cercano. La orquestación retrieve-and-generate por encima (chunking, query rewriting, reranking) vive en el pack RAG Pipelines para que las dos decisiones queden independientes.

Por qué elegir deliberadamente

La mayoría de equipos pasa sus primeros seis meses con el vector DB equivocado y solo lo descubre cuando algo se rompe. Los dos modos de fallo:

• Empezaron con Pinecone, llegaron a dolor de facturación a escala. El precio por-pod de Pinecone tiene sentido a 1M vectores pero empieza a verse caro a 50M. Migrar fuera requiere re-embed.
• Empezaron auto-alojado, llegaron a dolor de ops a escala. Un equipo con un nodo Chroma acumula 30M vectores, descubre que los índices ANN de un solo nodo no degradan con gracia — la latencia query va de 50ms a 800ms en un trimestre.

Elegir deliberadamente significa mirar tres ejes:

1. Recall vs latencia a tu cantidad de vectores. ANN-Benchmarks publica curvas recall@10 vs QPS; Qdrant y Pinecone lideran consistentemente >10M vectores, Chroma va bien debajo de 5M.
2. Necesidades de búsqueda híbrida. Si tus queries mezclan filtros por palabra clave con similitud semántica, el modo híbrido de Weaviate y los filtros payload de Qdrant son los diferenciadores — empernar BM25 a Chroma después es doloroso.
3. Postura de operaciones. Si tu equipo es de dos ingenieros, "sin servidores que cuidar" de Pinecone gana. Si ya corres Postgres a escala, pgvector (en el pack Postgres para Agentes IA) suele ganar a todas las opciones aquí en TCO.

Instala en un comando

# Instala el pack completo en el proyecto actual
tokrepo install pack/vector-db-showdown

# O elige recursos individuales
tokrepo install qdrant-mcp
tokrepo install chroma

El TokRepo CLI instala snippets Docker Compose para opciones auto-alojadas, plantillas de variables de entorno para APIs gestionadas, y scripts de benchmark que cargan 100k vectores y miden latencia query p95 en tu hardware.

Errores comunes

• Benchmarkear con vectores aleatorios. Vectores aleatorios tienen distribuciones de distancia planas — todo índice se ve igual de rápido. Benchmarkea siempre con embeddings reales de tu dominio (los dumps de Wikipedia funcionan como proxy público).
• Elegir métrica de distancia equivocada. Coseno vs dot product vs L2 dan rankings distintos sobre los mismos datos. Empareja la métrica con la que el modelo embedding fue entrenado; OpenAI text-embedding-3 espera coseno, algunos open models esperan dot product.
• Ignorar el lock-in del modelo embedding. Si embed 100M docs con Cohere y quieres cambiar a OpenAI, re-embedeas todo. Algunos equipos guardan ambos modelos embedding en paralelo durante la transición.
• Tratar "vector DB" como solución RAG completa. Ninguna de estas herramientas rerankea, reescribe queries o evalúa calidad de resultados. Empareja con el pack RAG Pipelines y el pack LLM Eval.
• Subestimar cardinalidad de filtro. Pre-filtrar por un campo de alta cardinalidad (e.g. user_id) antes de búsqueda ANN devasta el recall en la mayoría de motores. Usa post-filtrado o construye índices por usuario.

Cuándo este pack solo no basta

Si tu dataset es pequeño (<1M vectores) y ya tienes Postgres, pgvector gana a toda opción aquí en simplicidad operativa — un servicio menos que monitorear. Si tus queries necesitan restricciones geográficas o de grafo además de similitud semántica, mira Neo4j con GDS u OpenSearch con k-NN — distintos tradeoffs pero más limpio para esas formas. Y si operas a 1B+ vectores, has superado este pack; habla con vendors sobre tiers dedicados Vespa o Milvus.