Cápsula 02: Los límites concretos de ChromaDB en producción

Descripción de la cápsula

ChromaDB es excelente — para la fase del proyecto en la que estás cuando empiezas a aprender RAG. Es local, gratis, simple, sin barreras. Pero hay un punto donde sus limitaciones empiezan a romper tu producto. Esta cápsula te enseña a identificar ese punto con criterios objetivos, no por intuición. El objetivo es que ni migres demasiado pronto (complejidad innecesaria) ni demasiado tarde (incidentes en producción).

Vas a ver los cuatro límites concretos que ChromaDB no resuelve a escala (latencia, RAM, replicación, operacional), las señales objetivas que indican que es hora de migrar, y el framework de decisión que te permite defender la elección con datos ante un Tech Lead o un VP.

Al finalizar esta cápsula serás capaz de:

• ✅ Identificar los cuatro límites estructurales de ChromaDB para producción
• ✅ Cuantificar el threshold (con datos) donde la migración se justifica
• ✅ Construir un "scorecard" de readiness para tomar la decisión
• ✅ Defender la decisión (migrar o no) con argumentos numéricos
• ✅ Anticipar el costo total de NO migrar (riesgo de incidentes)
• ✅ Diferenciar las dos trampas: migración prematura y migración tardía

Tiempo estimado: 25-30 minutos

Los cuatro límites estructurales

ChromaDB no fue diseñado para producción a gran escala. No es defecto — es trade-off explícito de la herramienta. Conocer los límites te permite usarla bien.

Límite 1: latencia degrada con el corpus

Tamaño del corpus    Latency p95 típica (ChromaDB local)
─────────────────────────────────────────────────────────
10K vectors          5-10ms
100K vectors         15-30ms
1M vectors           80-150ms
5M vectors           300-600ms
10M+ vectors         1000ms+ (frecuentemente unusable)

Por qué pasa: ChromaDB carga el índice HNSW en RAM. A más vectores, más RAM, más cache misses, más swapping. Las queries tocan más nodos del grafo HNSW.

Pinecone: distribuye el índice across nodes. Latencia p95 se mantiene en 20-50ms hasta billones de vectores.

Límite 2: RAM como cuello de botella

# Estimación de RAM para HNSW (text-embedding-3-small, 1536 dim)
def ram_for_hnsw(n_vectors: int, m: int = 32) -> float:
    """RAM en GB."""
    bytes_per_vector = 1536 * 4  # float32
    overhead_factor = 1 + (m * 8 * 5 / bytes_per_vector)  # links + metadata
    total_bytes = n_vectors * bytes_per_vector * overhead_factor
    return total_bytes / 1e9


print(f"100K: {ram_for_hnsw(100_000):.1f} GB")    # ~0.7 GB
print(f"1M:   {ram_for_hnsw(1_000_000):.1f} GB")  # ~7 GB
print(f"5M:   {ram_for_hnsw(5_000_000):.1f} GB")  # ~35 GB
print(f"10M:  {ram_for_hnsw(10_000_000):.1f} GB") # ~70 GB

Implicaciones:

• 10M vectors no caben en una VM estándar (típicamente 16-64 GB).
• Necesitarías VM de 128+ GB → costo ~$500/mes en cloud.
• Si la app + sistema operativo + caches comparten esa RAM, problemas.

Pinecone: maneja petabytes sin que tú pienses en RAM. Es su problema.

Límite 3: sin replicación nativa

ChromaDB local en una VM = single point of failure.

• Si la VM cae, tu RAG está abajo.
• Si el disco se corrompe, pierdes datos.
• Si necesitas deploy con zero-downtime, no puedes (ChromaDB no soporta hot-swap de instancias).

Soluciones manuales (todas operacionalmente caras):

• ChromaDB en server mode + load balancer + replicación manual = mucho trabajo.
• Backups con cron + plan de DR = horas de mantenimiento mensual.

Pinecone: replicación automática across regions. SLA 99.95-99.99% según plan. DR built-in.

Límite 4: operacional pesado para equipos chicos

Tareas operacionales con ChromaDB self-hosted:
  - Monitoreo (Prometheus + Grafana)
  - Alerting (Pagerduty integrado)
  - Backups regulares + tests de restore
  - Updates de versión (con re-index si es breaking)
  - Tuning de HNSW params según crecimiento
  - Manejo de incidentes (latencia, OOM, disk full)

Tiempo estimado: 10-20 hrs/mes para un equipo experimentado

Para un equipo de 3-4 ingenieros, dedicar 1-2 personas part-time a operar ChromaDB es 30-50% del headcount disponible. Para equipos chicos, ese costo de oportunidad es enorme.

Pinecone: todo lo anterior está incluido. Tu equipo gasta 0 horas en operar la vector DB.

Señales objetivas de migración

Tu sistema te avisa cuándo es hora. Si reconoces alguno de estos síntomas, es momento de evaluar Pinecone:

Síntoma 1: latencia p95 creciendo orgánicamente

Mes 1: p95 = 50ms (corpus 200K)
Mes 6: p95 = 180ms (corpus 800K)
Mes 12: p95 = 400ms (corpus 2M) ← rompe SLA

Tu sistema funcionaba — ahora no. La causa raíz no es código, es escala.

Síntoma 2: RAM en VM al 90%+ sostenido

# Monitor
$ free -h
              total        used        free
Mem:          32G          29G         800M  ← 92% used, alerta

Estás cerca de OOM. Próximo crecimiento del corpus → la app se cae.

Síntoma 3: incidentes operacionales repetidos

• Caída de la VM por OOM una vez por semana.
• Recuperación toma 2-4 horas (re-cargar índice HNSW desde disk).
• Backups manuales fallan ocasionalmente sin alertar.

Cada incidente cuesta tiempo de ingeniería + reputación con clientes.

Síntoma 4: stakeholder pide SLA con uptime medible

Cliente premium: "Necesitamos 99.9% uptime garantizado en contrato.
                  ¿Cuál es tu SLA actual?"

Tú: "Eh... ¿depende?"

Sin SLA medible y respaldable, pierdes contratos enterprise.

Síntoma 5: equipo dedica >10 hrs/mes a operar la vector DB

Tracking de tiempo: si tu equipo está fixing problemas de ChromaDB en lugar de construir features, el costo de oportunidad supera el costo de Pinecone.

Scorecard de readiness para migrar

Construye esta matriz de decisión para tu propio sistema:

# migration_scorecard.py

def calculate_migration_score(metrics: dict) -> dict:
    """
    Score de 0-10 indicando readiness para migrar.
    Score 0-3: NO migrar (prematuro)
    Score 4-6: Evaluar, planificar
    Score 7-10: Migrar pronto
    """
    score = 0
    reasons = []

    # 1. Tamaño del corpus
    n_docs = metrics.get("total_documents", 0)
    if n_docs > 5_000_000:
        score += 3
        reasons.append("corpus > 5M (forzoso)")
    elif n_docs > 1_000_000:
        score += 2
        reasons.append("corpus > 1M (recomendado)")
    elif n_docs > 100_000:
        score += 1
        reasons.append("corpus > 100K (evaluar)")

    # 2. Latencia
    p95 = metrics.get("p95_latency_ms", 0)
    if p95 > 500:
        score += 2
        reasons.append(f"p95 latency {p95}ms (rompiendo SLA)")
    elif p95 > 250:
        score += 1
        reasons.append(f"p95 latency {p95}ms (alto)")

    # 3. RAM usage
    ram_pct = metrics.get("ram_usage_pct", 0)
    if ram_pct > 90:
        score += 2
        reasons.append(f"RAM {ram_pct}% (peligro OOM)")
    elif ram_pct > 75:
        score += 1
        reasons.append(f"RAM {ram_pct}% (sostenido alto)")

    # 4. Tiempo operacional
    ops_hrs_month = metrics.get("ops_hours_per_month", 0)
    if ops_hrs_month > 20:
        score += 2
        reasons.append(f"{ops_hrs_month}h/mes operacional (caro)")
    elif ops_hrs_month > 10:
        score += 1
        reasons.append(f"{ops_hrs_month}h/mes operacional")

    # 5. Compliance / SLA
    if metrics.get("sla_required", False):
        score += 2
        reasons.append("SLA requerido por contratos")
    elif metrics.get("hipaa_or_gdpr_strict", False):
        score += 1
        reasons.append("Compliance estricto")

    # 6. Incidentes
    incidents_last_3mo = metrics.get("incidents_last_3mo", 0)
    if incidents_last_3mo > 3:
        score += 1
        reasons.append(f"{incidents_last_3mo} incidentes recientes")

    # Normalizar a 0-10
    score = min(score, 10)

    if score <= 3:
        recommendation = "NO migrar todavía. Optimiza ChromaDB."
    elif score <= 6:
        recommendation = "Empezar planificación de migración. POC con Pinecone."
    else:
        recommendation = "Migrar pronto. Riesgo de incidente alto."

    return {
        "score": score,
        "recommendation": recommendation,
        "reasons": reasons,
    }


# Ejemplo de uso
my_metrics = {
    "total_documents": 2_500_000,
    "p95_latency_ms": 420,
    "ram_usage_pct": 88,
    "ops_hours_per_month": 15,
    "sla_required": True,
    "incidents_last_3mo": 4,
}

result = calculate_migration_score(my_metrics)
print(f"Score: {result['score']}/10")
print(f"Recommendation: {result['recommendation']}")
print("Razones:")
for r in result['reasons']:
    print(f"  - {r}")

Output esperado:

Score: 9/10
Recommendation: Migrar pronto. Riesgo de incidente alto.
Razones:
  - corpus > 1M (recomendado)
  - p95 latency 420ms (alto)
  - RAM 88% (sostenido alto)
  - 15h/mes operacional
  - SLA requerido por contratos
  - 4 incidentes recientes

Las dos trampas opuestas

Trampa 1: migración prematura

El error: corpus de 50K docs, equipo de 2 personas, sin presión real. Alguien lee un blog post y propone migrar a Pinecone.

Síntoma: dedican 2 semanas a la migración. Pagas $50/mes que no necesitabas. La complejidad extra te resta velocidad de iteración.

Cómo prevenir: scorecard primero. Si score <4, no migrar. Si tu producto necesita iterar rápido, ChromaDB local es mejor.

Trampa 2: migración tardía (peor)

El error: sistema crece a 8M docs, p95 está en 800ms, hay 5 incidentes/trimestre. Equipo está prendiendo fuegos. Nadie tiene tiempo para "el proyecto de migrar a Pinecone".

Síntoma: un día la VM se cae, perder 4 horas para recuperar, cliente premium pide reembolso por incumplimiento de SLA. La migración que hubiera tomado 3 semanas planificada ahora hay que hacerla en 1 semana bajo presión, con bugs.

Cómo prevenir: monitorear el scorecard cada trimestre. Si pasa de 5/10, planear migración para próximos 3-6 meses. No esperar que sea inevitable.

Comparación cuantitativa: TCO real

Setup A: ChromaDB self-hosted (5M docs, 2 réplicas)
  - VM 64 GB RAM × 2: $400/mes
  - Storage SSD: $50/mes
  - Bandwidth: $30/mes
  - Equipo dedicado (15 hrs × $80/h): $1200/mes
  - Costo de incidentes (estimado): $200/mes
  Total: ~$1880/mes

Setup B: Pinecone Standard (5M docs)
  - Plan Standard: $400/mes
  - Equipo dedicado: 0 hrs
  - Costo de incidentes: ~$0 (SLA 99.95%)
  Total: ~$400/mes

Diferencia: Pinecone es ~$1500/mes MÁS BARATO para corpus 5M+

Lectura clave: Pinecone parece "caro" si solo miras la factura. Sumando costo de equipo + incidentes, generalmente es más barato a escala.

Trampas y errores comunes

Trampa 1: "Pinecone es caro"

El error: comparar solo el precio del plan vs ChromaDB "gratis" sin contar tiempo del equipo + incidentes.

Cómo prevenir: TCO completo (visto arriba).

Trampa 2: migrar sin validar calidad

El error: migras, pero no mides precision/recall después. Asumes que es igual.

Síntoma: algunos cambios sutiles en filter syntax o defaults rompen retrieval, calidad cae 5% sin que te enteres.

Cómo prevenir: correr eval set ANTES y DESPUÉS de la migración. Si calidad cae >2%, investigar.

Trampa 3: migración "big bang"

El error: un solo deploy gigante migra todo de una vez.

Síntoma: algo falla, no puedes rollback fácil, hay downtime extendido.

Cómo prevenir: migración gradual (cubierto en cápsula 04): staging → 10% tenants → 50% → 100%.

Trampa 4: olvidar audit trail durante migración

El error: durante la transición, queries van a Pinecone pero los logs siguen apuntando a ChromaDB. Si algo falla, no puedes debuggear.

Cómo prevenir: dual logging durante transición. Loggear en ambos sistemas hasta validar.

Ejercicio aplicado

Escenario: eres AI Engineer en una startup B2B SaaS. Datos del sistema:

• Corpus: 1.8M docs (creció de 200K hace 1 año)
• p95 latency: 380ms (subió de 80ms)
• Incidentes último trimestre: 6 (4 OOM, 2 disco lleno)
• Equipo: 4 ingenieros, 0 DevOps dedicado
• Tickets de operacional/mes: ~25h del equipo
• Cliente importante quiere SLA 99.9% en contrato (no firmaron por esto)
• Presupuesto disponible: $1500/mes para infra

Tu trabajo:

1. Calcula el migration score.
2. Decide: ¿migrar ya, planificar, o quedarse?
3. Justifica con TCO comparativo.

my_metrics = {
    "total_documents": 1_800_000,
    "p95_latency_ms": 380,
    "ram_usage_pct": 85,  # asumir
    "ops_hours_per_month": 25,
    "sla_required": True,        # cliente lo pide
    "hipaa_or_gdpr_strict": False,
    "incidents_last_3mo": 6,
}

# Aplicando el scorecard:
# - Corpus 1.8M (>1M) → +2
# - p95 380ms (>250) → +1
# - RAM 85% (>75) → +1
# - 25h/mes ops (>20) → +2
# - SLA required → +2
# - 6 incidentes (>3) → +1
# Score: 9/10

Quedarse en ChromaDB (escenario optimista):
  - Infra: VM grande con más RAM ($600/mes)
  - Equipo (25h/mes × $100/h): $2500/mes
  - Incidentes (perder revenue + reputación): $500/mes
  - Cliente premium NO firmado: -$5000/mes (revenue perdido)
  Total efectivo: -$3400/mes

Migrar a Pinecone Standard:
  - Pinecone: $400/mes
  - Migración inicial (40 hrs × $100): $4000 (one-time)
  - Equipo operacional: $0
  - Cliente premium firmado (con SLA): +$5000/mes
  Total mensual: +$4600/mes (después del setup)

Diferencia: +$8000/mes a favor de migrar

Resumen y siguiente paso

Lo que aprendiste:

• Cuatro límites de ChromaDB en producción: latencia con escala, RAM cap, sin replicación, operacional pesado.
• Señales objetivas: latencia creciendo, RAM al 90%+, incidentes recurrentes, SLA pedido, 10+ hrs/mes operacional.
• Scorecard de readiness con 6 dimensiones permite decisión basada en datos, no intuición.
• Dos trampas opuestas: migración prematura (complejidad innecesaria) y tardía (incidentes).
• TCO real incluye costo del equipo + incidentes + revenue perdido por falta de SLA, no solo factura mensual.

Checkpoint: antes de avanzar, deberías poder:

• Calcular tu migration score actual.
• Defender la decisión (migrar o no) con argumentos numéricos.
• Comparar TCO honesto entre ambas opciones.

Siguiente cápsula: 03 — Setup de Pinecone serverless.

Decidiste migrar. La cápsula 03 te enseña a configurar tu primer índice en Pinecone — serverless (no tienes que pensar en infraestructura), con dimensiones y métrica correctas según el modelo de embeddings que ya usas.

Recursos

1. Pinecone — When to Migrate — Guía de decisión
2. Pinecone Pricing — Para TCO real
3. SRE Book — Service Level Objectives — Para SLAs
4. Latency Percentiles Best Practices — Medición correcta
5. Vector DB Comparison — ChromaDB vs Pinecone vs otros
6. Anthropic — Contextual Retrieval — Patrón complementario

Tiempo estimado: 25-30 minutos Siguiente: 03-pinecone-setup-and-indexes.md