Módulo 1: Por qué Vector Databases para AI Engineers

Cuándo SÍ necesitas vector database

Siguiente →

Descripción de la cápsula

Has visto las limitaciones de SQL, NoSQL y numpy. Ahora la pregunta crítica: ¿Cuándo SÍ necesitas una vector database?

Esta cápsula te da criterios claros y cuantitativos para decidir. No es "siempre usa vector DB" ni "nunca uses numpy". Es: "SI cumples estos 4 criterios, vector DB es necesaria. Si no, alternatives pueden ser suficientes."

Al final de esta cápsula, podrás evaluar tu proyecto RAG en 5 minutos y decidir si necesitas vector DB o no.

Los 4 criterios de decisión

Criterio 1: Scale (# de vectores)

Regla simple:

<1K vectores:    numpy suficiente  (prototipo)
1K-10K vectores: numpy aceptable   (desarrollo)
10K-100K:        zona gris          (evaluar latency)
>100K vectores:  vector DB necesaria (producción)

Por qué 100K es el punto de inflexión:

  • numpy con 100K: ~150ms latency (límite aceptable)
  • numpy con 500K: ~750ms latency (inutilizable para RAG)
  • ChromaDB con 100K: ~8ms (excelente)
  • ChromaDB con 500K: ~12ms (excelente)

Cálculo rápido:

# Estima # de vectores en tu proyecto
docs = 50_000  # documentos
chunks_per_doc = 3  # promedio de chunks por doc
total_vectors = docs * chunks_per_doc

print(f"Total vectores: {total_vectors:,}")
# Output: Total vectores: 150,000

# Decisión:
if total_vectors > 100_000:
    print("→ Vector DB necesaria")
else:
    print("→ numpy puede ser suficiente (evaluar latency)")

Criterio 2: Latency (<500ms retrieval)

Regla simple:

Latency requirement   | Opción
----------------------|-------------------
Sin requisito         | numpy (batch processing)
<5s                   | numpy/SQL pueden servir
<1s                   | Zona gris (evaluar)
<500ms                | Vector DB necesaria
<100ms                | Vector DB obligatoria

Por qué <500ms es crítico:

RAG total latency:

Query embedding:  200ms  (OpenAI API)
Retrieval:        ???ms  (búsqueda en vectores)
Generation:     2,500ms  (GPT-4)
-----------------------------------
Total:         2,700ms + retrieval

Para cumplir <3s total:

  • Retrieval debe ser: 3000ms - 2700ms = <300ms
  • Idealmente <100ms (buffer para variabilidad)

Benchmark tu setup:

import numpy as np
import time

# Tu database actual
embeddings = np.load('your_embeddings.npy')  # Shape: (n_vectors, 1536)
query = np.random.randn(1536)

# Medir latency
start = time.time()
similarities = np.dot(embeddings, query)
top_5 = np.argsort(similarities)[-5:][::-1]
latency_ms = (time.time() - start) * 1000

print(f"Retrieval latency: {latency_ms:.1f}ms")

# Decisión:
if latency_ms > 500:
    print("→ Vector DB necesaria (numpy muy lento)")
elif latency_ms > 100:
    print("→ Zona gris (vector DB recomendada si crecerá)")
else:
    print("→ numpy suficiente (por ahora)")

Criterio 3: Persistencia (storage duradero)

Regla simple:

Tipo de deployment    | Persistencia | Opción
----------------------|--------------|------------------
Jupyter notebook      | No crítica   | numpy en memoria
Script one-off        | No crítica   | numpy + .npy save
Servicio con uptime   | Crítica      | Vector DB necesaria
API production        | Crítica      | Vector DB obligatoria

Por qué persistencia importa:

Sin persistencia robusta (numpy):

  • Reinicio/crash = pérdida de datos O recarga de 30-60s
  • Deployment = downtime de 30-60s (recargar embeddings)
  • Corruption risk (proceso interrumpido durante .save())

Con persistencia (Vector DB):

  • Reinicio/crash = reconexión <1ms (índice persiste)
  • Deployment = zero downtime (índice ya en disk)
  • ACID transactions (no corruption)

Evaluación:

¿Tu servicio necesita uptime 99%+?
├─ SÍ → Vector DB necesaria
└─ NO → numpy puede servir

¿Toleras 30-60s downtime en cada deploy?
├─ SÍ → numpy puede servir
└─ NO → Vector DB necesaria

¿Tienes >10K vectores que tardan horas en generar?
├─ SÍ → Vector DB necesaria (no quieres perder trabajo)
└─ NO → numpy puede servir (re-generar es rápido)

Criterio 4: Concurrencia (múltiples usuarios)

Regla simple:

# de usuarios concurrentes | Opción
---------------------------|-------------------
1 usuario (desarrollo)     | numpy suficiente
2-10 usuarios              | Zona gris
>10 usuarios concurrentes  | Vector DB necesaria
>100 usuarios              | Vector DB obligatoria

Por qué concurrencia importa:

numpy no es thread-safe para writes:

import numpy as np
from threading import Thread

embeddings = np.load('embeddings.npy')

# ❌ Race condition: múltiples usuarios agregando docs
def add_doc(user_id, doc_embedding):
    global embeddings
    embeddings = np.vstack([embeddings, doc_embedding])  # ❌ Not thread-safe
    np.save('embeddings.npy', embeddings)  # ❌ Corruption risk

# Múltiples requests concurrentes
threads = [Thread(target=add_doc, args=(i, emb)) for i, emb in enumerate(new_docs)]
for t in threads: t.start()

Vector DB thread-safe:

import chromadb

client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_collection("docs")

# ✅ Thread-safe: múltiples usuarios pueden add concurrentemente
def add_doc(user_id, doc_embedding, doc_id):
    collection.add(embeddings=[doc_embedding], ids=[doc_id])  # ✅ Safe

# Múltiples requests concurrentes → Sin problemas

Evaluación:

¿Cuántos usuarios usarán tu sistema simultáneamente?
├─ 1-2 (desarrollo/demo) → numpy suficiente
├─ 3-10 (equipo pequeño) → numpy con locks (complicado) O vector DB (simple)
└─ >10 (production) → Vector DB necesaria

¿Necesitas agregar/actualizar docs mientras otros consultan?
├─ SÍ → Vector DB necesaria (maneja read/write concurrentemente)
└─ NO → numpy puede servir (read-only)

Matriz de decisión completa

Combina los 4 criterios

ScaleLatencyPersistenciaConcurrenciaDecisión
<10K>1sNo crítica1 usuario✅ numpy suficiente
<10K<500msNo crítica1-5 usuarios⚠️ numpy/SQL (zona gris)
10K-100K<500msCrítica>5 usuarios⚠️ Vector DB recomendada
>100K<500msCrítica>10 usuarios✅ Vector DB necesaria
>500K<100msCrítica>50 usuarios✅ Vector DB obligatoria

Casos de uso: Cuándo SÍ necesitas

Caso 1: Chatbot de soporte técnico (empresa)

Requisitos:

  • 500,000 artículos de documentación (1.5M chunks)
  • 1,000 empleados usando simultáneamente
  • <3s respuesta total (<500ms retrieval)
  • Uptime 99.9% (24/7)

Evaluación:

  • Scale: 1.5M vectores → ✅ Vector DB necesaria
  • Latency: <500ms → ✅ Vector DB necesaria
  • Persistencia: 99.9% uptime → ✅ Vector DB necesaria
  • Concurrencia: 1,000 usuarios → ✅ Vector DB necesaria

Decisión: ✅ Vector DB necesaria (4/4 criterios cumplidos)

Recomendación:

  • Development: ChromaDB local (gratis, rápido)
  • Production: Pinecone managed ($200-500/mes) o ChromaDB self-hosted en server robusto

Caso 2: Q&A sobre documentos legales (startup)

Requisitos:

  • 50,000 documentos legales (150K chunks)
  • 50 abogados internos usando
  • <2s respuesta total (<300ms retrieval)
  • Uptime 99% (horario laboral)

Evaluación:

  • Scale: 150K vectores → ✅ Vector DB recomendada
  • Latency: <300ms → ✅ Vector DB recomendada
  • Persistencia: 99% uptime → ✅ Vector DB recomendada
  • Concurrencia: 50 usuarios → ✅ Vector DB recomendada

Decisión: ✅ Vector DB recomendada (4/4 criterios)

Recomendación:

  • ChromaDB self-hosted (gratis, suficiente para 150K vectores)
  • O Pinecone ($70-150/mes) si prefieren managed

Caso 3: Sistema RAG multi-tenant (SaaS)

Requisitos:

  • 100 clientes, cada uno con 10K-50K documentos
  • Total: 1M-5M vectores (aggregado)
  • <100ms retrieval (competitivo)
  • Multi-tenancy (aislamiento de datos por cliente)
  • Uptime 99.99% (SLA contractual)

Evaluación:

  • Scale: 1M-5M vectores → ✅ Vector DB obligatoria
  • Latency: <100ms → ✅ Vector DB obligatoria
  • Persistencia: 99.99% uptime → ✅ Vector DB obligatoria
  • Concurrencia: 100s-1000s usuarios → ✅ Vector DB obligatoria
  • Plus: Multi-tenancy → ✅ Vector DB con feature nativa

Decisión: ✅ Vector DB obligatoria + managed preferred

Recomendación:

  • Pinecone managed ($500-2000/mes) - mejor opción para multi-tenant SaaS
  • O Weaviate Cloud ($300-1000/mes) - flexible, GraphQL API
  • NO ChromaDB self-hosted (requiere manejo de multi-tenancy manual)

Caso 4: Research paper search (personal)

Requisitos:

  • 100,000 papers científicos (300K chunks)
  • 1 usuario (investigador)
  • <1s retrieval (análisis exploratorio)
  • Local en laptop (privacidad)

Evaluación:

  • Scale: 300K vectores → ⚠️ Zona gris (numpy tarda ~500ms)
  • Latency: <1s → ⚠️ numpy podría servir (~500ms aceptable para exploración)
  • Persistencia: Local laptop → ⚠️ No crítica (tolerás reload)
  • Concurrencia: 1 usuario → ✅ numpy suficiente

Decisión: ⚠️ Zona gris (2/4 criterios no favorecen vector DB)

Opciones:

  1. numpy + pgvector (Postgres local):

    • Setup moderado (install Postgres + pgvector)
    • 50-80ms retrieval (suficiente para exploración)
    • Persistencia mejor que numpy raw

  2. ChromaDB local:

    • pip install chromadb (simple)
    • 15-30ms retrieval (excelente)
    • Persistencia nativa

  3. numpy raw:

    • pip install numpy (más simple)
    • 500ms retrieval (aceptable para 1 usuario explorando)
    • Sin persistencia (recarga 60s después de reinicio)

Recomendación: ChromaDB local (mejor balance simplicidad/performance)

Señales claras de que necesitas vector DB

SI respondes "SÍ" a 3+ de estas:

  1. ✅ Tienes >100K vectores (o crecerás a eso)
  2. ✅ Necesitas <500ms retrieval latency
  3. ✅ Necesitas uptime >99% (production service)
  4. ✅ Tienes >10 usuarios concurrentes
  5. ✅ Necesitas metadata filtering (categoría, fecha, autor)
  6. ✅ Necesitas agregar/actualizar docs dinámicamente
  7. ✅ Necesitas backup/restore robusto
  8. ✅ Necesitas monitoring (latency, throughput, usage)

→ Vector DB es necesaria

SI respondes "NO" a todas:

  • Solo tienes <1K vectores
  • No importa latency (batch processing)
  • No necesitas uptime (script one-off)
  • 1 solo usuario (desarrollo)
  • No necesitas features avanzadas
  • No agregarás docs dinámicamente
  • No necesitas backup/monitoring

→ numpy es suficiente

Resumen

Lo que aprendiste:

  1. ✅ Criterio 1: Scale - >100K vectores → vector DB necesaria
  2. ✅ Criterio 2: Latency - <500ms → vector DB recomendada, <100ms → obligatoria
  3. ✅ Criterio 3: Persistencia - uptime >99% → vector DB necesaria
  4. ✅ Criterio 4: Concurrencia - >10 usuarios → vector DB necesaria
  5. ✅ Matriz de decisión - Combina criterios para decidir

Casos típicos:

  • Production RAG (empresa): 4/4 criterios → Vector DB necesaria
  • Prototipo/MVP: 0-1/4 criterios → numpy suficiente
  • Zona gris: 2/4 criterios → Evaluar trade-offs (simplicidad vs performance)

Por qué importa:

  • No sobre-ingenierizar: Si numpy cumple requisitos, úsalo (simplicidad)
  • No sub-ingenierizar: Si necesitas vector DB, no pierdas tiempo con numpy (performance)
  • Decisión informada = tiempo ahorrado

Siguiente cápsula: Ahora que sabes cuándo SÍ necesitas vector DB, verás cuándo NO (casos donde alternatives son mejores).

Recursos adicionales

  1. Choosing a Vector Database - Decision framework
  2. ChromaDB vs Pinecone - Self-hosted vs managed
  3. RAG at Scale - Production considerations
  4. Vector DB Benchmarks - Performance comparisons
  5. Multi-tenant RAG - SaaS use case
  6. Vector Database Comparison - Landscape overview

Tiempo de lectura: 6-8 minutos
Siguiente: 06-cuando-no-necesitas-vector-database.md

← AnteriorPor qué numpy/pandas no escalan a producciónSiguiente →Cuándo NO necesitas vector database