Cápsula 02: Panorama de Proveedores de Vector DB

🎯 Objetivo de la cápsula

Mapear el landscape actual de vector databases para RAG: entender qué problema resuelve mejor cada opción, cómo se diferencia de las demás, y cuándo es la elección correcta para tu proyecto.

El mercado de bases de datos vectoriales ha crecido significativamente desde 2021. Lo que empezó como extensiones de búsqueda sobre bases existentes (pgvector, Elasticsearch kNN) se ha convertido en un ecosistema de soluciones especializadas, cada una con filosofía de diseño, modelo de negocio y audiencia distintos. Para un AI Engineer, la clave no es memorizar specs de cada proveedor sino desarrollar una forma de evaluarlos rápido: ¿qué problema resuelve? ¿para quién? ¿a qué costo operativo?

Esta cápsula cubre los cinco proveedores más relevantes para sistemas RAG en 2025-2026: ChromaDB, Pinecone, Weaviate, Qdrant y Milvus. No busca declarar un ganador; busca darte criterio para que la decisión se base en datos y contexto, no en tendencias de Twitter.

Al finalizar esta cápsula:

• ✅ Conocerás origen, arquitectura y diferenciadores de 5 vector databases
• ✅ Identificarás la audiencia objetivo de cada proveedor
• ✅ Compararás ecosistemas y SDKs con ejemplos de código
• ✅ Tendrás un mapa mental claro del landscape para alimentar tu decision tree

Tiempo estimado: 20-25 minutos

🗺️ El Landscape: Vista General

Antes de entrar proveedor por proveedor, conviene entender las dimensiones del mercado:

                    Managed (Cloud-first)
                         │
                    ┌────┴────┐
                    │Pinecone │
                    └─────────┘
                         │
        ┌────────────────┼────────────────┐
        │                │                │
   ┌────┴────┐     ┌────┴────┐     ┌────┴────┐
   │Weaviate │     │ Qdrant  │     │ Milvus  │
   │Cloud+OSS│     │Cloud+OSS│     │Cloud+OSS│
   └─────────┘     └─────────┘     └─────────┘
        │                │                │
        └────────────────┼────────────────┘
                         │
                    ┌────┴────┐
                    │ChromaDB │
                    │  (OSS)  │
                    └─────────┘
                         │
                  Self-hosted / Local

Categorías clave:

1️⃣ ChromaDB

Origen y filosofía

ChromaDB nació en 2022 como una respuesta directa a la fricción de trabajar con vectores en prototipos de LLM. Su filosofía es "the AI-native open-source embedding database": prioriza experiencia de desarrollador sobre features enterprise. Fundada por Jeff Huber y Anton Troynikov, levantó $18M Series A en 2023.

Filosofía de diseño: La base vectorial más simple posible para que puedas ir de pip install a semantic search en menos de 5 minutos.

Arquitectura

ChromaDB Architecture
┌─────────────────────────────────┐
│           Client API            │
│    (Python / JavaScript SDK)    │
├─────────────────────────────────┤
│         Collection Layer        │
│   ┌───────────┐ ┌───────────┐  │
│   │Collection │ │Collection │  │
│   │    A      │ │    B      │  │
│   └───────────┘ └───────────┘  │
├─────────────────────────────────┤
│       Embedding Functions       │
│  (Built-in o custom providers)  │
├─────────────────────────────────┤
│       Index Layer (HNSW)        │
├─────────────────────────────────┤
│     Storage: SQLite + DuckDB    │
│     (Persistent o in-memory)    │
└─────────────────────────────────┘

• Index: HNSW (hnswlib) para approximate nearest neighbor search.
• Storage: SQLite para metadata, DuckDB/Parquet para embeddings.
• Modos: In-memory (efímero) o persistent (disco local).
• Server mode: Client/server con FastAPI (desde v0.4+).

SDK — Ejemplo Python

import chromadb

client = chromadb.PersistentClient(path="./chroma_db")

collection = client.get_or_create_collection(
    name="tech_docs",
    metadata={"hnsw:space": "cosine"}
)

collection.add(
    documents=["FastAPI es un framework web moderno para Python"],
    metadatas=[{"source": "docs", "language": "es"}],
    ids=["doc_001"]
)

results = collection.query(
    query_texts=["framework web rápido en Python"],
    n_results=5,
    where={"language": "es"}
)
print(results["documents"])

Diferenciadores clave

Audiencia objetivo

• Desarrolladores aprendiendo RAG o vector databases.
• Equipos en fase de PoC / MVP.
• Proyectos académicos y notebooks de Colab.
• Aplicaciones con < 500K vectores y tráfico bajo.

Ecosistema

• LangChain: integración nativa.
• LlamaIndex: integración nativa.
• Embedding providers: OpenAI, Cohere, HuggingFace, Sentence Transformers.
• Community: Activa en Discord, crecimiento rápido.

2️⃣ Pinecone

Origen y filosofía

Pinecone fue fundada en 2019 por Edo Liberty (ex-jefe de investigación en AWS AI Labs). Es la primera vector database diseñada 100% como servicio managed. No hay opción self-hosted — esto es intencional: Pinecone quiere que nunca pienses en infraestructura.

Filosofía de diseño: "Vector search as a service". Cero operación, máxima velocidad para llegar a producción.

Arquitectura

Pinecone Architecture (Serverless)
┌─────────────────────────────────┐
│         Pinecone API            │
│     (REST + gRPC + SDKs)        │
├─────────────────────────────────┤
│        Index Management         │
│   ┌──────────┐ ┌──────────┐    │
│   │Serverless│ │  Pod-    │    │
│   │  Index   │ │  based   │    │
│   └──────────┘ └──────────┘    │
├─────────────────────────────────┤
│      Distributed Storage        │
│   (S3-backed, proprietary)      │
├─────────────────────────────────┤
│     Multi-AZ Replication        │
│     (AWS regions)               │
└─────────────────────────────────┘

• Index types: Serverless (escala automática, pay-per-use) y Pod-based (capacidad dedicada).
• Replicación: Multi-AZ automática.
• Storage: Propietario, optimizado para read-heavy workloads.
• No self-hosted: Solo cloud.

SDK — Ejemplo Python

from pinecone import Pinecone

pc = Pinecone(api_key="YOUR_API_KEY")

index = pc.Index("tech-docs")

index.upsert(
    vectors=[
        {
            "id": "doc_001",
            "values": [0.1, 0.2, 0.3, ...],  # 1536-dim
            "metadata": {"source": "docs", "language": "es"}
        }
    ],
    namespace="production"
)

results = index.query(
    vector=[0.1, 0.2, 0.3, ...],
    top_k=5,
    filter={"language": {"$eq": "es"}},
    namespace="production",
    include_metadata=True
)
print(results.matches)

Diferenciadores clave

Audiencia objetivo

• Startups y equipos pequeños que necesitan producción rápida.
• Empresas que priorizan time-to-market sobre control de infra.
• Proyectos donde el costo de un engineer manteniendo infra supera el costo del servicio.
• Equipos sin DevOps dedicado.

Ecosistema

• LangChain / LlamaIndex: Integración de primera clase.
• Canopy: Framework RAG propio de Pinecone.
• Pinecone Assistant: Producto de alto nivel sobre el index.
• SDKs: Python, Node.js, Go, Java, Rust.
• Integraciones: Cohere, OpenAI, Anthropic, Vercel AI SDK.

3️⃣ Weaviate

Origen y filosofía

Weaviate fue creada en 2019 en los Países Bajos por Bob van Luijt. Su diferenciador desde el origen es ser una vector database con capacidades de knowledge graph: puedes definir esquemas con relaciones, usar módulos de vectorización y combinar búsqueda semántica con keyword en una sola query (hybrid search nativo).

Filosofía de diseño: "The AI-native database" — una base vectorial que entiende relaciones entre objetos, no solo similitud.

Arquitectura

Weaviate Architecture
┌─────────────────────────────────┐
│          GraphQL + REST API     │
├─────────────────────────────────┤
│       Schema / Class Layer      │
│   (typed objects + properties)  │
├─────────────────────────────────┤
│  Vectorizer Modules             │
│  ┌──────────┐ ┌──────────┐     │
│  │text2vec- │ │text2vec- │     │
│  │openai    │ │cohere    │     │
│  └──────────┘ └──────────┘     │
├─────────────────────────────────┤
│       Index: HNSW + BM25        │
│    (Hybrid search nativo)       │
├─────────────────────────────────┤
│     Storage: LSM Tree           │
│   (Custom, crash-recovery)      │
└─────────────────────────────────┘

• Index: HNSW para vectores + BM25 invertido para keyword.
• Hybrid search: Fusión RRF nativa (no requiere sistema externo).
• Modules: Vectorización pluggable (OpenAI, Cohere, HuggingFace, etc.).
• Multi-tenancy: Nativa desde v1.20 (activity-based).
• Disponibilidad: Open-source (BSD-3) + Weaviate Cloud Services (WCS).

SDK — Ejemplo Python

import weaviate
import weaviate.classes as wvc

client = weaviate.connect_to_local()

collection = client.collections.create(
    name="TechDocs",
    vectorizer_config=wvc.config.Configure.Vectorizer.text2vec_openai(),
    properties=[
        wvc.config.Property(name="content", data_type=wvc.config.DataType.TEXT),
        wvc.config.Property(name="source", data_type=wvc.config.DataType.TEXT),
    ]
)

collection.data.insert(
    properties={"content": "FastAPI es un framework web moderno", "source": "docs"}
)

response = collection.query.hybrid(
    query="framework web rápido en Python",
    alpha=0.5,
    limit=5,
    filters=wvc.query.Filter.by_property("source").equal("docs")
)
for obj in response.objects:
    print(obj.properties["content"])

client.close()

Diferenciadores clave

Audiencia objetivo

• Equipos que necesitan hybrid search sin infraestructura adicional.
• Proyectos con datos relacionales + semánticos (e-commerce, knowledge bases).
• Equipos que quieren flexibilidad de self-hosted con opción cloud.
• Casos donde multi-tenancy nativa es requisito (SaaS).

Ecosistema

• LangChain / LlamaIndex: Integración robusta.
• Verba: RAG app open-source de Weaviate.
• Modules: 20+ módulos de vectorización, generación, reranking.
• SDKs: Python (v4 client), TypeScript, Go, Java.
• Community: Activa, Weaviate Academy gratuita.

4️⃣ Qdrant

Origen y filosofía

Qdrant (pronunciado "quadrant") fue fundada en 2021 en Berlín por Andrey Vasnetsov. Está escrita en Rust, lo que le da ventajas de rendimiento y seguridad de memoria. Su foco es performance sólida con API limpia — un punto medio entre la simplicidad de ChromaDB y la escala de Milvus.

Filosofía de diseño: "Vector search engine" — rápido, predecible, con API REST/gRPC limpia y excelente experiencia self-hosted.

Arquitectura

Qdrant Architecture
┌─────────────────────────────────┐
│       REST + gRPC API           │
├─────────────────────────────────┤
│      Collection Management      │
│   ┌──────────┐ ┌──────────┐    │
│   │Collection│ │Collection│    │
│   │  (shards)│ │  (shards)│    │
│   └──────────┘ └──────────┘    │
├─────────────────────────────────┤
│     Index: HNSW (custom)        │
│  + Payload Index (filtrable)    │
├─────────────────────────────────┤
│  Storage: RocksDB / mmap        │
│  (On-disk + in-memory hybrid)   │
├─────────────────────────────────┤
│  Distributed: Raft consensus    │
│  (Sharding + Replication)       │
└─────────────────────────────────┘

• Lenguaje: Rust (performance, safety).
• Index: HNSW custom + quantization (scalar, product, binary).
• Storage: RocksDB para persistencia, mmap para acceso rápido.
• Distribución: Raft consensus para clusters multi-nodo.
• Disponibilidad: Open-source (Apache 2.0) + Qdrant Cloud.

SDK — Ejemplo Python

from qdrant_client import QdrantClient
from qdrant_client.models import (
    VectorParams, Distance, PointStruct, Filter,
    FieldCondition, MatchValue
)

client = QdrantClient(host="localhost", port=6333)

client.create_collection(
    collection_name="tech_docs",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE)
)

client.upsert(
    collection_name="tech_docs",
    points=[
        PointStruct(
            id=1,
            vector=[0.1, 0.2, 0.3, ...],
            payload={"source": "docs", "language": "es"}
        )
    ]
)

results = client.query_points(
    collection_name="tech_docs",
    query=[0.1, 0.2, 0.3, ...],
    limit=5,
    query_filter=Filter(
        must=[FieldCondition(key="language", match=MatchValue(value="es"))]
    )
)
for point in results.points:
    print(point.payload)

Diferenciadores clave

Audiencia objetivo

• Equipos técnicos que valoran performance y control.
• Proyectos que necesitan self-hosted con buena experiencia operativa.
• Casos donde quantization es importante para reducir memoria.
• Equipos que prefieren Rust ecosystem y APIs limpias.

Ecosistema

• LangChain / LlamaIndex: Integración completa.
• Fastembed: Librería de Qdrant para embeddings locales.
• SDKs: Python, TypeScript, Rust, Go, Java, C#.
• Dashboard: UI web incluida para explorar collections.
• Community: Creciendo rápido, documentación excelente.

5️⃣ Milvus

Origen y filosofía

Milvus fue creado en 2019 por Zilliz, empresa fundada por Charles Xie. Es el proyecto de vector database más grande en la Linux Foundation (LF AI & Data). Su diseño está orientado a escala enterprise: millones a billones de vectores, clusters distribuidos, separación de storage y compute.

Filosofía de diseño: "The world's most advanced open-source vector database" — escala masiva, cloud-native, separación de responsabilidades.

Arquitectura

Milvus Architecture (Distributed)
┌─────────────────────────────────┐
│          SDK / REST API         │
├─────────────────────────────────┤
│         Proxy Layer             │
│   (Load balancing, routing)     │
├─────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐    │
│  │  Query   │  │  Data    │    │
│  │  Nodes   │  │  Nodes   │    │
│  └──────────┘  └──────────┘    │
├─────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐    │
│  │  Index   │  │  Root    │    │
│  │  Nodes   │  │  Coord   │    │
│  └──────────┘  └──────────┘    │
├─────────────────────────────────┤
│     Storage: S3 / MinIO         │
│     Meta: etcd                  │
│     Message: Pulsar / Kafka     │
└─────────────────────────────────┘

• Distributed: Separación completa de compute, storage y coordinación.
• Dependencias: etcd (meta), MinIO/S3 (storage), Pulsar/Kafka (messaging).
• Indexes: IVF_FLAT, IVF_SQ8, IVF_PQ, HNSW, DiskANN, GPU indexes.
• Milvus Lite: Versión embebida para desarrollo local (similar a ChromaDB).
• Disponibilidad: Open-source (Apache 2.0) + Zilliz Cloud.

SDK — Ejemplo Python

from pymilvus import MilvusClient

client = MilvusClient(uri="http://localhost:19530")

client.create_collection(
    collection_name="tech_docs",
    dimension=1536,
    metric_type="COSINE"
)

client.insert(
    collection_name="tech_docs",
    data=[
        {
            "id": 1,
            "vector": [0.1, 0.2, 0.3, ...],
            "source": "docs",
            "language": "es"
        }
    ]
)

results = client.search(
    collection_name="tech_docs",
    data=[[0.1, 0.2, 0.3, ...]],
    limit=5,
    filter='language == "es"',
    output_fields=["source", "language"]
)
print(results)

Diferenciadores clave

Audiencia objetivo

• Organizaciones con volúmenes masivos (> 100M vectores).
• Equipos con plataforma dedicada y experiencia en Kubernetes.
• Casos que requieren GPU-accelerated search.
• Enterprise con requisitos de separación de storage y compute.

Ecosistema

• LangChain / LlamaIndex: Integración completa.
• Attu: Dashboard web para gestión visual.
• Milvus Lite: Desarrollo local sin dependencias.
• SDKs: Python, Java, Go, Node.js, C#, RESTful.
• Zilliz Cloud: Managed service con free tier.

📊 Tabla Comparativa General

*ChromaDB está desarrollando un cloud offering, pero no está disponible a escala en 2026.

🔍 Comparación de SDKs: Mismo Problema, Cinco Enfoques

Para ver las diferencias en experiencia de desarrollador, comparemos cómo cada SDK resuelve el mismo flujo básico: crear colección, insertar un documento y buscar.

Patrón de query con filtro

# ChromaDB — text-based, embedding automático
results = collection.query(
    query_texts=["búsqueda semántica"],
    n_results=5,
    where={"category": "tutorial"}
)

# Pinecone — vector obligatorio, filter syntax MongoDB-like
results = index.query(
    vector=embedding,
    top_k=5,
    filter={"category": {"$eq": "tutorial"}}
)

# Weaviate — GraphQL-inspired, alpha para hybrid
response = collection.query.hybrid(
    query="búsqueda semántica",
    alpha=0.5,
    limit=5,
    filters=Filter.by_property("category").equal("tutorial")
)

# Qdrant — filter model, typed
results = client.query_points(
    collection_name="docs",
    query=embedding,
    limit=5,
    query_filter=Filter(must=[FieldCondition(key="category", match=MatchValue(value="tutorial"))])
)

# Milvus — SQL-like filter string
results = client.search(
    collection_name="docs",
    data=[embedding],
    limit=5,
    filter='category == "tutorial"'
)

Observación: Cada SDK refleja la filosofía del proveedor. ChromaDB prioriza simplicidad (text-in, results-out). Pinecone usa sintaxis MongoDB. Weaviate es GraphQL-like. Qdrant usa modelos tipados. Milvus usa SQL-like strings.

🔧 Troubleshooting de decisión

1. "Todas parecen buenas, no sé por dónde empezar"

Causa: Estás comparando sin criterios definidos.

Solución: Define tus 3 restricciones principales antes de mirar proveedores:

1. ¿Cuántos vectores necesito almacenar (hoy y en 12 meses)?
2. ¿Tengo equipo DevOps para self-hosted?
3. ¿Qué latencia p95 necesito?

Con esas tres respuestas, eliminas al menos 2-3 opciones inmediatamente.

2. "No tengo datos de costo reales"

Causa: Los proveedores no siempre publican pricing transparente.

Solución: Haz estimación con tres escenarios:

• Conservador: 100K vectores, 10 queries/segundo
• Esperado: 1M vectores, 50 queries/segundo
• Agresivo: 10M vectores, 200 queries/segundo

Usa las calculadoras de pricing de Pinecone y Zilliz Cloud para estimar el tier managed.

3. "El equipo está dividido entre dos opciones"

Causa: Faltan criterios explícitos con pesos.

Solución: Documenta 5 criterios, asigna pesos (1-5), y que cada persona vote sin ver los votos de los demás. Luego compara scores. El debate debe ser sobre criterios, no sobre marcas.

4. "Mi caso es muy pequeño, ¿importa la elección?"

Causa: Para < 100K vectores casi todas funcionan igual.

Solución: Si estás en MVP o PoC, usa ChromaDB. Define un trigger explícito de reevaluación (ej: al superar 500K vectores o necesitar SLA). No inviertas tiempo en comparar proveedores hasta que el problema de escala sea real.

✏️ Ejercicios

Ejercicio 1: Mapa mental del landscape

Crea un mapa mental (papel o herramienta digital) con los 5 proveedores. Para cada uno escribe:

• 1 fortaleza principal
• 1 debilidad principal
• 1 caso de uso ideal

Ejercicio 2: Matching proveedor-escenario

Asigna el proveedor más adecuado a cada escenario:

1. Hackathon de 48 horas, 5K documentos.
2. SaaS B2B con 50 clientes, cada uno con sus documentos aislados.
3. Empresa de e-commerce con 80M productos y equipo de plataforma.
4. Startup de 4 personas que necesita RAG en producción en 2 semanas.
5. Proyecto de investigación con 2M papers y queries con IDs de paper exactos.

Ejercicio 3: Comparación de SDKs

Implementa el siguiente flujo con ChromaDB y compáralo conceptualmente con el pseudocódigo de Pinecone:

1. Crear colección con distancia coseno
2. Insertar 3 documentos con metadata {"category": "tutorial"}
3. Buscar "cómo optimizar queries" filtrando por categoría
4. Imprimir los 2 resultados más relevantes

import chromadb

client = chromadb.PersistentClient(path="./ejercicio_db")
collection = client.get_or_create_collection(
    name="ejercicio",
    metadata={"hnsw:space": "cosine"}
)

collection.add(
    documents=[
        "Optimización de queries en bases de datos vectoriales",
        "Cómo mejorar latencia en búsquedas semánticas",
        "Guía de indexación para RAG"
    ],
    metadatas=[
        {"category": "tutorial"},
        {"category": "tutorial"},
        {"category": "tutorial"}
    ],
    ids=["doc_1", "doc_2", "doc_3"]
)

results = collection.query(
    query_texts=["cómo optimizar queries"],
    n_results=2,
    where={"category": "tutorial"}
)

for doc, dist in zip(results["documents"][0], results["distances"][0]):
    print(f"Score: {1 - dist:.4f} | {doc}")

Ejercicio 4: Auditoría de ecosistema

Para un proyecto RAG que usa LangChain + OpenAI embeddings + FastAPI, investiga:

1. ¿Cuáles de los 5 proveedores tienen integración oficial con LangChain?
2. ¿Cuáles ofrecen embedding automático (sin generar externamente)?
3. ¿Cuáles tienen dashboard web para explorar datos?

Ejercicio 5: Elevator pitch

Escribe un "elevator pitch" de 2-3 oraciones para recomendar un proveedor a tu equipo. Incluye:

• El proveedor elegido
• El caso de uso específico
• La razón principal de la recomendación
• El riesgo principal a monitorear

🔗 Conexión con proyecto (Decision Tree)

El proyecto de este módulo es construir un decision tree para elegir vector database. Esta cápsula te dio la materia prima:

• Nodos de decisión: ¿equipo tiene DevOps? ¿escala > 1M? ¿necesita hybrid search?
• Hojas del árbol: Cada proveedor como recomendación final con justificación.
• Criterios: Complejidad operativa, costo, features, escala.

En las próximas cápsulas sumarás los ejes de managed vs self-hosted, features para RAG y costos para completar tu decision tree.

📝 Resumen

• ChromaDB es la opción de menor fricción para aprendizaje y prototipos — no la uses para producción a gran escala.
• Pinecone resuelve producción sin operación, pero con vendor lock-in total y costo creciente.
• Weaviate destaca en hybrid search nativo y multi-tenancy, con mayor curva de aprendizaje.
• Qdrant ofrece el mejor balance de performance (Rust) y facilidad self-hosted, con quantization avanzada.
• Milvus es para escala masiva y enterprise — no lo uses si tu problema no lo requiere.
• Cada SDK refleja la filosofía del proveedor: compara la experiencia de desarrollo, no solo features.
• La elección correcta depende de 3 ejes: escala, capacidad operativa y features críticas de tu RAG.
• No hay ganador universal; hay mejor opción para tu contexto específico.

📚 Recursos adicionales

• ChromaDB Docs — Documentación oficial y getting started
• Pinecone Docs — Reference API y guides de producción
• Weaviate Docs — Conceptos, módulos y tutorials
• Qdrant Docs — Guides, API reference y benchmarks
• Milvus Docs — Arquitectura, SDKs y deployment
• ANN Benchmarks — Benchmarks independientes de algoritmos ANN
• Vector Database Comparison (Superlinked) — Comparativa actualizada con filtros
• MTEB Leaderboard — Para elegir embedding model (complemento)

Tiempo de lectura: 20-25 minutos Siguiente: 03-managed-vs-self-hosted.md