Módulo 5: Landscape de Vector Databases para AI Engineers

Descripción del módulo

Cerraste el Módulo 4 con un sistema RAG funcional end-to-end. Construiste el Document Search System de 10K documentos (M4/01-08), tomaste decisiones conscientes sobre embeddings (M4/09: OpenAI sobre el default), aplicaste chunking justificado (M4/10), y operaste el pipeline completo de retrieve + generate con citas y anti-alucinación (M4/11). Tienes código que funciona, benchmarks que confirman latency aceptable, y un sistema RAG mínimo viable que sirve de base directa al proyecto integrador del Módulo 8. La tentación natural es decir "listo, ya tengo mi vector database" y seguir adelante.

Pero hay un problema que ese enfoque ignora: ChromaDB no es la única opción, y dependiendo de tu proyecto, puede no ser la mejor. En el mercado actual existen al menos cinco alternativas serias — Pinecone, Weaviate, Qdrant, Milvus y ChromaDB — cada una con arquitectura distinta, modelo operativo diferente y trade-offs que solo se hacen visibles cuando tu proyecto crece de prototipo a producción. Elegir la correcta (o cambiar a tiempo) puede significar la diferencia entre un sistema RAG que escala sin dolor y uno que requiere migración de emergencia a las 3am un viernes.

Este módulo no te pide que instales cinco tecnologías diferentes. Te enseña algo más valioso: un framework de evaluación reusable que puedes aplicar a cualquier vector database que aparezca mañana en Product Hunt. Cuando termine el módulo, no solo conocerás las opciones actuales — tendrás la capacidad de evaluar opciones futuras con el mismo rigor.

🧠 El problema: elegir vector database es más difícil de lo que parece

Por qué la mayoría elige mal

Si buscas "best vector database 2026" en Google, encontrarás:

Blog posts de vendors que casualmente recomiendan su propio producto
Benchmarks cherry-picked que miden exactamente las dimensiones donde gana su producto
Tutoriales "Getting Started" que te muestran lo fácil que es empezar (pero no lo difícil que es operar)
Threads en Reddit/Twitter con opiniones fuertes pero sin criterios claros

El resultado es que la mayoría de equipos elige vector database por una de estas razones:

Inercia: "Uso Pinecone porque el tutorial que seguí lo usaba"
Hype: "Uso Weaviate porque tiene más GitHub stars esta semana"
Comodidad: "Uso ChromaDB porque ya lo tengo instalado del módulo anterior"
Precio superficial: "Uso el más barato sin considerar costo operativo"
Fear of commitment: "No elijo ninguno y sigo con numpy en producción"

Ninguna de estas es una razón técnica válida. Y todas llevan al mismo lugar: migración costosa 3-6 meses después cuando los requisitos reales del proyecto colisionan con las limitaciones de la elección apresurada.

El costo real de elegir mal

Cuando tu elección de vector database falla, el impacto no es solo técnico:

Migración de datos: Re-indexar 1M+ vectores puede tomar días y requiere downtime
Cambio de API: Tu código de retrieval está acoplado al SDK del vendor
Reentrenamiento de equipo: Tus developers aprenden una API nueva desde cero
Pérdida de confianza: Stakeholders cuestionan decisiones futuras del equipo técnico
Costo financiero: Dual-running de dos databases durante migración = 2x costo por semanas

La habilidad que falta

Lo que necesitas no es "conocer todos los vendors". Necesitas un proceso sistemático de evaluación que considere:

Requisitos reales del proyecto (no los imaginados)
Capacidades del equipo (¿pueden operar self-hosted?)
Modelo operativo (¿managed vs self-hosted?)
Escala actual Y proyectada (¿100K hoy pero 10M en 12 meses?)
Presupuesto total (no solo tarifa mensual, sino TCO)

Este módulo desarrolla exactamente esa habilidad.

🎯 Objetivo del módulo

Objetivo profesional:

Comprender el panorama actual de vector databases para RAG, evaluar cada opción con criterios objetivos (features, costo, operación, escala) y construir un decision tree reusable que cualquier AI Engineer de tu equipo pueda seguir para tomar decisiones informadas.

¿Por qué es importante para un AI Engineer?

Como AI Engineer, vas a enfrentarte a esta conversación:

Tech Lead: "¿Qué vector database vamos a usar para el sistema RAG?"
Tú:        "ChromaDB para desarrollo, Pinecone para producción"
Tech Lead: "¿Por qué Pinecone y no Qdrant? ¿Cuánto cuesta? 
            ¿Qué pasa si necesitamos multi-tenancy?"
Tú:        "..."

Si no puedes justificar tu elección con criterios técnicos claros, pierdes credibilidad profesional. Este módulo te prepara para esa conversación con argumentos basados en datos, no en preferencias personales.

Al finalizar este módulo, serás capaz de:

Describir las fortalezas y limitaciones de 5 vector databases principales
Comparar managed vs self-hosted con criterios objetivos de costo y operación
Evaluar features específicas para RAG (filtering, hybrid search, multi-tenancy)
Calcular costo total de propiedad (TCO), no solo precio de lista
Construir un decision tree que recomiende vector DB según requisitos concretos
Comunicar trade-offs a stakeholders técnicos y no técnicos

📚 Contenido del módulo — Roadmap detallado

Cápsula 01: Introducción al módulo (estás aquí)

Aspecto	Detalle
Tema	Contexto, objetivos y roadmap del módulo
Pregunta clave	¿Por qué elegir vector database es un problema de ingeniería, no de preferencia?
Entregable	Claridad sobre qué aprenderás y cómo conecta con el proyecto
Tiempo	8-10 min

Cápsula 02: Panorama de proveedores

Aspecto	Detalle
Tema	Overview de ChromaDB, Pinecone, Weaviate, Qdrant y Milvus
Pregunta clave	¿Qué problema resuelve cada uno y para quién está diseñado?
Entregable	Mapa mental de 5 proveedores con positioning claro
Tiempo	12-15 min

Qué aprenderás:

Historia y filosofía de diseño de cada proveedor
Target audience (startup vs enterprise vs researcher)
Modelo de negocio (open-source, open-core, managed-only)
Comunidad y ecosistema (integraciones, SDKs, soporte)

Cápsula 03: Managed vs self-hosted

Aspecto	Detalle
Tema	Trade-offs operativos entre managed cloud y self-hosted
Pregunta clave	¿Mi equipo puede (y debería) operar su propia infraestructura vectorial?
Entregable	Checklist de criterios para elegir modelo operativo
Tiempo	10-12 min

Qué aprenderás:

Qué significa "managed" realmente (y qué NO incluye)
Costo oculto de self-hosted (DevOps, monitoring, upgrades)
Cuándo managed es obligatorio (compliance, SLA, equipo pequeño)
Cuándo self-hosted tiene sentido (costo a escala, data sovereignty)

Cápsula 04: Comparación de features para RAG

Aspecto	Detalle
Tema	Features técnicas comparadas entre los 5 proveedores
Pregunta clave	¿Qué features realmente importan para un sistema RAG en producción?
Entregable	Tabla comparativa de features críticas
Tiempo	12-15 min

Qué aprenderás:

Metadata filtering (capacidades y limitaciones por vendor)
Hybrid search (dense + sparse vectors)
Multi-tenancy (isolation, namespaces, collections)
Observabilidad (métricas, logs, tracing)
Batch operations y performance de ingestion

Cápsula 05: Costos y trade-offs

Aspecto	Detalle
Tema	Costo total de propiedad, no solo tarifa de servicio
Pregunta clave	¿Cuánto cuesta REALMENTE operar cada opción a 12 meses?
Entregable	Framework de cálculo de TCO aplicable a cualquier vendor
Tiempo	10-12 min

Qué aprenderás:

Pricing models (por vector, por query, por storage, flat rate)
Costos ocultos (egress, embeddings re-generation, migration)
TCO a 6 y 12 meses para 3 escenarios (startup, mid-scale, enterprise)
Cuándo "gratis" sale más caro que "de pago"

Cápsula 06: Cuándo elegir cada opción

Aspecto	Detalle
Tema	Reglas prácticas de selección por contexto de proyecto
Pregunta clave	Dado MI proyecto, ¿cuál es la mejor opción y por qué?
Entregable	Decision rules aplicables a proyectos reales
Tiempo	10-12 min

Qué aprenderás:

Reglas por tamaño de equipo (1 dev, 3-5 devs, 10+ devs)
Reglas por escala de datos (10K, 100K, 1M, 10M+ vectores)
Reglas por requisito de SLA (hobby, startup, enterprise)
Reglas por restricciones (presupuesto, compliance, latency)

Cápsula 07: Anti-patrones de selección

Aspecto	Detalle
Tema	Errores frecuentes en la selección de vector database
Pregunta clave	¿Qué errores debo evitar cuando evalúo y selecciono?
Entregable	Catálogo de anti-patrones con señales de alerta
Tiempo	8-10 min

Qué aprenderás:

"Resume-Driven Development" (elegir tech para el CV, no para el proyecto)
"Benchmark Tourism" (comparar benchmarks sintéticos vs carga real)
"Lock-in Blindness" (ignorar costos de migración futura)
"Premature Scaling" (Pinecone Enterprise para un MVP de 5K vectores)
"Open-source Fallacy" (asumir que open-source = gratis operativamente)

Cápsula 08: Proyecto — Decision Tree

Aspecto	Detalle
Tema	Construir flowchart de decisión para elegir vector DB
Pregunta clave	¿Puedo crear un artefacto que otro engineer pueda seguir?
Entregable	Decision tree visual + documento justificativo
Tiempo	25-30 min

Qué construirás:

Flowchart con 8-12 nodos de decisión
Cada nodo con pregunta + criterios de evaluación
Documento que justifica cada rama del árbol
Validación con 3 escenarios reales (startup, mid-scale, enterprise)

⏱️ Tiempo estimado

Lectura + análisis: 95-130 minutos

Cápsula	Tema	Tiempo
01	Introducción al módulo	8-10 min
02	Panorama de proveedores	12-15 min
03	Managed vs self-hosted	10-12 min
04	Comparación de features para RAG	12-15 min
05	Costos y trade-offs	10-12 min
06	Cuándo elegir cada opción	10-12 min
07	Anti-patrones de selección	8-10 min
08	Proyecto — Decision Tree	25-30 min
Total		95-130 min

Nota: Este módulo es 70% análisis, 30% proyecto. No hay código que ejecutar (ese fue Módulo 4). Aquí el trabajo es pensar, comparar y decidir. Planea tiempo para reflexionar sobre tus propios requisitos mientras lees.

🔗 Conexión con otros módulos

Vienes de:

Módulo 4: ChromaDB Setup y Configuración

Ya sabes instalar, configurar y operar ChromaDB localmente
Tienes experiencia hands-on con HNSW, metadata filtering, batch ingestion
Construiste Document Search System con 10K documentos
Conoces las fortalezas de ChromaDB de primera mano

Módulos 1-3: Fundamentos conceptuales

Entiendes por qué RAG necesita vector databases (Módulo 1)
Conoces cómo funcionan internamente — HNSW, IVF, PQ (Módulo 2)
Sabes qué features buscar para RAG (Módulo 3)

Este módulo te prepara para:

Módulo 6: Decision Matrix para AI Engineers

Formalizarás la evaluación con scoring cuantitativo
Convertirás criterios cualitativos en pesos numéricos
Construirás cuestionario que recomiende DB automáticamente

Módulo 7: Production Considerations para RAG

Aplicarás tu elección de DB al contexto de producción
Scaling, monitoring, backups, migrations
Operarás la decisión que tomaste en Módulo 5-6

Módulo 8: Proyecto Integrador — RAG System con ChromaDB

Construirás sistema RAG completo con elección justificada
1,000+ documentos, API FastAPI, Docker
La justificación de "por qué ChromaDB" vendrá de este módulo

Flujo completo:

Módulos 1-3: Fundamentos (POR QUÉ y CÓMO vector DBs)
  ↓
Módulo 4: ChromaDB hands-on (IMPLEMENTAR con una DB)
  ↓
Módulo 5: Landscape ← Estás aquí (COMPARAR todas las opciones)
  ↓
Módulo 6: Decision Matrix (FORMALIZAR la decisión)
  ↓
Módulo 7-8: Production + Proyecto (OPERAR y CONSTRUIR)

🎓 ¿Qué aprenderás en este módulo?

Al finalizar este módulo, serás capaz de:

1. Mapear el landscape completo

✅ Describir las 5 vector databases principales (ChromaDB, Pinecone, Weaviate, Qdrant, Milvus)
✅ Identificar target audience y filosofía de diseño de cada una
✅ Distinguir open-source vs open-core vs managed-only
✅ Evaluar madurez de comunidad y ecosistema

2. Evaluar modelo operativo

✅ Comparar managed vs self-hosted con criterios objetivos
✅ Calcular costo real de operar self-hosted (no solo "es gratis")
✅ Identificar cuándo managed es obligatorio vs opcional
✅ Evaluar capacidad de tu equipo para operar infraestructura

3. Comparar features para RAG

✅ Evaluar metadata filtering, hybrid search, multi-tenancy por vendor
✅ Identificar gaps de features que afectan tu caso de uso
✅ Distinguir features "nice-to-have" vs "deal-breaker"
✅ Conectar features técnicas con requisitos de negocio

4. Calcular costo total

✅ Ir más allá de "precio por mes" hacia TCO real
✅ Incluir costos ocultos (DevOps, migration, training)
✅ Proyectar costos a 6-12 meses según crecimiento esperado
✅ Comparar escenarios (startup vs mid-scale vs enterprise)

5. Tomar decisiones con criterio

✅ Aplicar reglas de selección según contexto de proyecto
✅ Evitar anti-patrones comunes de selección
✅ Justificar elección con datos ante stakeholders
✅ Construir decision tree reusable

💡 Filosofía del módulo

Consultoría técnica, no marketing

Lo que NO encontrarás aquí:

❌ "Pinecone es la mejor opción porque..."
❌ "Siempre usa managed, self-hosted es legacy"
❌ "ChromaDB no sirve para producción"
❌ "Open-source siempre es mejor"

Lo que SÍ encontrarás:

✅ "Pinecone es óptimo CUANDO tus requisitos son X, Y, Z"
✅ "Managed tiene sentido SI tu equipo cumple estas condiciones"
✅ "ChromaDB en producción funciona HASTA cierta escala"
✅ "Open-source reduce costo de licencia pero no costo operativo"

La diferencia es sutil pero crucial: contexto. Ninguna tecnología es "la mejor" en abstracto. Toda recomendación depende de requisitos, equipo, presupuesto y timeline.

Por qué vendor-neutral importa

Si un vendor escribe la comparación, va a ganar su producto. Siempre.

Pinecone publicará benchmarks donde Pinecone gana. Weaviate publicará benchmarks donde Weaviate gana. Es natural — están vendiendo su producto.

Tu trabajo como AI Engineer no es creerle al que tiene mejor marketing. Es evaluar con tus propios criterios basados en TUS requisitos. Este módulo te da el framework para hacerlo.

La habilidad transferible

La capacidad de evaluar tecnologías con criterio objetivo no aplica solo a vector databases. Es la misma habilidad que necesitas para:

Elegir cloud provider (AWS vs GCP vs Azure)
Elegir framework web (FastAPI vs Flask vs Django)
Elegir modelo de LLM (GPT-4 vs Claude vs Gemini)
Elegir base de datos relacional (PostgreSQL vs MySQL vs SQLite)

Aprender a decidir con criterio > memorizar "la respuesta correcta".

🚫 Qué NO cubre este módulo

Este módulo NO cubre:

❌ Tutoriales de instalación por proveedor

No vas a instalar Pinecone, Weaviate, Qdrant ni Milvus
ChromaDB ya lo instalaste en Módulo 4
El foco es evaluación comparativa, no setup técnico

❌ Benchmarks exhaustivos de performance

No vamos a ejecutar benchmarks head-to-head
Los benchmarks públicos tienen contexto (y sesgo)
Aprenderás a LEER benchmarks críticamente, no a generarlos

❌ Pruebas reales en tu infraestructura

La evaluación final requiere probar en TU hardware con TU data
Este módulo te prepara para saber QUÉ probar y CÓMO interpretar resultados
Las pruebas reales son responsabilidad de tu equipo post-módulo

❌ Decision matrix cuantitativa (eso es Módulo 6)

Aquí desarrollas criterio cualitativo y decision tree
Módulo 6 formaliza con scoring numérico y pesos

❌ Production deployment (eso es Módulo 7)

Una vez que eliges, Módulo 7 cubre operación en producción
Scaling, monitoring, backups, migrations

Scope claro: Este módulo es sobre criterio técnico inicial y comunicación de trade-offs. Es la base para las decisiones formales de Módulos 6-8.

🎯 Conexión con el proyecto: Decision Tree

El proyecto de este módulo es práctico y reusable: construir un decision tree (flowchart) para elegir vector database según requisitos de proyecto.

¿Qué es un decision tree en este contexto?

Es un diagrama de flujo que cualquier AI Engineer puede seguir:

¿Cuántos vectores necesitas almacenar?
  ├── < 100K → ¿Necesitas managed cloud?
  │     ├── No → ChromaDB (local, gratis)
  │     └── Sí → ¿Presupuesto > $70/mes?
  │           ├── Sí → Pinecone Starter
  │           └── No → ChromaDB + VPS
  ├── 100K - 10M → ¿Tu equipo puede operar Kubernetes?
  │     ├── Sí → Qdrant/Weaviate self-hosted
  │     └── No → Pinecone/Weaviate Cloud
  └── > 10M → ¿Requisito de multi-tenancy?
        ├── Sí → Weaviate/Milvus
        └── No → Qdrant/Pinecone Enterprise

¿Por qué este proyecto?

Sintetiza todo el módulo en un artefacto accionable
Es reusable — lo puedes usar en proyectos reales post-curso
Es comunicable — lo puedes mostrar a un Tech Lead o CTO
Demuestra criterio — no solo "conozco las opciones" sino "sé cuándo elegir cada una"

Cómo se construye a lo largo del módulo

Cada cápsula aporta una dimensión al decision tree:

Cápsula	Aporte al Decision Tree
02 - Panorama	Nodos terminales (las 5 opciones)
03 - Managed vs self-hosted	Primera bifurcación (modelo operativo)
04 - Features	Criterios de filtrado (qué features necesitas)
05 - Costos	Restricciones de presupuesto en cada rama
06 - Cuándo elegir	Reglas de decisión por contexto
07 - Anti-patrones	Validación (qué NO hacer en cada nodo)
08 - Proyecto	Ensamblaje final + validación con escenarios

No llegas a Cápsula 08 vacío. Llegas con todas las piezas, listo para ensamblar.

✅ Criterios de éxito

Completaste exitosamente este módulo cuando:

Puedes responder estas preguntas:

✅ ¿Cuáles son las 5 principales vector databases y qué las diferencia?
- ChromaDB (local-first, open-source, ideal para prototipos y desarrollo)
- Pinecone (managed-only, serverless, baja fricción operativa)
- Weaviate (open-source, GraphQL API, módulos de vectorización built-in)
- Qdrant (open-source, Rust-based, alto performance, API gRPC)
- Milvus (open-source, cloud-native, diseñado para escala masiva)
✅ ¿Cuándo elegirías managed sobre self-hosted?
- Equipo pequeño (< 3 devs) sin DevOps dedicado
- Requisitos de SLA que tu equipo no puede garantizar solo
- Presupuesto que justifica pagar por operación vs operar internamente
- Timeline agresivo donde setup de infra no es prioridad
✅ ¿Qué es TCO y por qué "precio mensual" no es suficiente?
- TCO = tarifa + DevOps + training + migration + downtime + growth
- Un servicio "gratis" puede costar más si requiere 20h/mes de operación
- Un servicio "caro" puede costar menos si elimina necesidad de infra team
✅ ¿Qué anti-patrones debes evitar al seleccionar?
- Resume-Driven Development, Benchmark Tourism, Lock-in Blindness
- Premature Scaling, Open-source Fallacy
✅ ¿Puedes entregar un decision tree que otro engineer pueda seguir?
- Flowchart con 8-12 nodos de decisión
- Cada nodo con pregunta clara y criterios objetivos
- Validado con al menos 3 escenarios reales

Si respondiste 4-5/5 correctamente Y entregaste decision tree → ✅ Módulo completado

🧩 Mini checklist de preparación

Antes de iniciar este módulo, asegúrate de tener claras estas preguntas sobre TU contexto:

¿Cuántos vectores necesita mi proyecto actual (o hipotético)?
¿Cuál es mi requisito de latency? (< 100ms, < 500ms, < 2s)
¿Mi equipo tiene capacidad para operar infraestructura self-hosted?
¿Cuál es mi presupuesto mensual para vector database?
¿Tengo requisitos de compliance o data sovereignty?
¿Entiendo que "precio mensual" no es lo mismo que costo total de propiedad?

No necesitas respuestas definitivas. Pero tener estos puntos en mente hará que cada cápsula conecte directamente con tu realidad profesional.

📖 Cómo usar este módulo

Estrategia recomendada:

Lee secuencialmente (Cápsulas 01 → 02 → ... → 08)
- Cada cápsula construye sobre la anterior
- Los criterios de decisión se acumulan progresivamente
- No saltes a Cápsula 06 ("cuándo elegir") sin Cápsulas 02-05
Piensa en tu proyecto real mientras lees
- Cada cápsula invita a conectar con TUS requisitos
- "¿Esto aplica a mi caso?" es la pregunta más valiosa
- Si no tienes proyecto real, usa los escenarios hipotéticos del módulo
Toma notas para el decision tree
- Cada cápsula aporta un criterio o dimensión
- Al llegar a Cápsula 08, necesitarás todo acumulado
- Recomendación: anota en un doc separado mientras avanzas
No busques "la respuesta correcta"
- No hay una vector database universalmente mejor
- Hay opciones óptimas para contextos específicos
- Tu job es aprender a evaluar, no memorizar rankings

Tiempo sugerido:

Opción A: Dos sesiones (recomendado)

Sesión 1: Cápsulas 01-04 (landscape, modelo operativo, features) = 45-55 min
Sesión 2: Cápsulas 05-08 (costos, decisión, anti-patrones, proyecto) = 55-70 min

Opción B: Una sesión intensa

Todo de corrido = 95-130 min
Ventaja: Contexto fresco para el decision tree
Desventaja: Mucha información para procesar de golpe

Recomendación: Opción A (dos sesiones). La primera te da el panorama, la segunda te da criterio de decisión. El break entre sesiones te ayuda a procesar.

Resumen

Módulo 5 desarrolla criterio vendor-neutral para elegir vector database
Después de la experiencia hands-on con ChromaDB (Módulo 4), toca levantar la mirada y evaluar el mercado completo
Cubrirás 5 opciones principales: ChromaDB, Pinecone, Weaviate, Qdrant, Milvus
Aprenderás a evaluar managed vs self-hosted, features para RAG y costo total de propiedad
Identificarás anti-patrones comunes que llevan a malas decisiones
El proyecto final es un decision tree reusable que podrás aplicar en proyectos reales
La habilidad central — evaluar tecnologías con criterio objetivo — es transferible a cualquier decisión técnica futura
Es la base conceptual para la Decision Matrix formal (Módulo 6) y las consideraciones de producción (Módulo 7)

🔗 Recursos adicionales

Documentación oficial de proveedores:

ChromaDB Documentation — Open-source, local-first
Pinecone Documentation — Managed, serverless
Weaviate Documentation — Open-source, GraphQL
Qdrant Documentation — Open-source, Rust-based
Milvus Documentation — Open-source, cloud-native

Comparaciones independientes:

DB-Engines Vector DBMS Ranking — Ranking por popularidad (no calidad, pero útil para entender adoption)
ANN Benchmarks — Benchmarks de Approximate Nearest Neighbors (lee con criterio, no como verdad absoluta)
VectorDB Comparison by Superlinked — Comparativa mantenida por la comunidad

Nota: Los recursos de vendors tienen sesgo natural. Úsalos para entender features, no para decidir quién "gana". Las comparaciones independientes son mejor punto de partida, pero también tienen limitaciones.

🚀 ¿Listo para empezar?

Próximo paso:

Ve a Cápsula 02: Panorama de proveedores

Ahí conocerás:

Las 5 vector databases principales y su filosofía de diseño
Para quién está diseñada cada una (target audience)
Modelo de negocio y sostenibilidad de cada proyecto
Comunidad, ecosistema e integraciones disponibles

Esta cápsula es la base de todo el módulo. No puedes comparar lo que no conoces.

Tiempo de lectura: 8-10 minutos
Siguiente: 02-panorama-proveedores.md

← AnteriorCápsula 11: Pipeline RAG end-to-end con ChromaDB Siguiente →Cápsula 02: Panorama de Proveedores de Vector DB