En el post anterior entendimos qué son los embeddings. Hoy bajamos a diseño de almacenamiento y recuperación: ¿cuándo usar una base de datos vectorial dedicada y cuándo resolverlo con tu base relacional y una extensión?

¿Qué es una base de datos vectorial?

Es un sistema diseñado para indexar, almacenar y consultar vectores (embeddings) de forma eficiente. Su valor está en los índices aproximados (ANN) que equilibran velocidad, memoria y precisión cuando tienes millones de vectores y necesitas respuestas en milisegundos.

• Operaciones: upsert de vectores, filtros por metadatos, consultas por similitud, refresco de índices.
• Índices típicos: HNSW (grafo jerárquico), IVF/Flat, PQ/OPQ, ScaNN/DiskANN, entre otros.
• Metadatos y filtros: combinar similitud con filtros (fecha, etiqueta, idioma, tenant…)

¿Cuándo conviene una vector DB dedicada?

• Volumen: > 1–5 millones de vectores o crecimiento sostenido mensual.
• Latencia: objetivos de <100 ms p95 con alto recall.
• Concurrencia: muchas consultas simultáneas (chat, búsqueda, recomendaciones).
• Ops: necesitas replicación, particionado y mantenimiento del índice con poca fricción.
• Roadmap: planeas hibridar keyword + vector, multimodal (imagen/audio) o re-ranking.

¿Cuándo no la necesitas (todavía)?

• Pocos datos: decenas o cientos de miles de vectores → un índice exacto o ANN sencillo en Postgres puede ir perfecto.
• Bajo QPS: consultas esporádicas (interna, backoffice) sin SLA agresivo.
• Prototipo: priorizas simplicidad y time-to-first-value.
• Dominio estable: corpus pequeño, poco cambiante, donde reconstruir índice no es problema.

En estos casos, evalúa PostgreSQL + pgvector (o MySQL con soporte de vectores) para mantener todo en un solo motor, con transacciones, joins y tus herramientas conocidas.

Opciones comunes en 2025

Guía de decisión rápida

1. < 500k vectores, bajo QPS, sin SLA estricto → Postgres + pgvector.
2. 0.5–5M vectores, QPS medio, filtros + reindexado regular → evalúa pgvector HNSW vs. una vector DB.
3. > 5M vectores o p95 < 100 ms con alta concurrencia → vector DB dedicada.
4. ¿Multimodal o hibridación keyword+vector? → favorece vector DB con soporte nativo de híbrido.

Patrones prácticos

• Híbrido keyword+vector: primero filtra por metadatos/keyword, luego similitud sobre el subconjunto.
• Re-ranking: tras el Top-K por vector, reordena con un LLM o un modelo de ranking más preciso.
• TTL/archivado: mueve embeddings antiguos a almacenamiento frío para ahorrar.
• Idempotencia: calcula un content hash por fragmento para evitar upserts duplicados.

Micro-workflow n8n: “ingesta y búsqueda híbrida”

1. Webhook → recibe documento o URL.
2. HTTP → extrae texto y metadatos.
3. Function → chunking + content hash.
4. HTTP → servicio de embeddings → guarda {vector, texto, metadatos, hash}.
5. Webhook (consulta) → filtra por metadatos + recupera Top-K por similitud.
6. LLM → responde con citas; si baja confianza, pide contexto adicional.

Errores comunes (y cómo evitarlos)

• Embebes documentos completos: usa fragmentos (300–800 tokens) con solapes pequeños.
• Sin metadatos: perderás precisión y gastarás más tokens/tiempo en búsqueda.
• Índice único para todo: separa por tenant/idioma para mejorar calidad y coste.
• No monitorizas recall@K, latencia y coste por query.

Conclusión

Una vector DB no es un fin, es un medio. Usa lo que resuelva tu escala y tus SLA: empieza simple con tu SQL, valida con métricas y, si lo exige el crecimiento, migra a una base vectorial dedicada con índices ANN más avanzados.

← Anterior: Embeddings sin mística: cómo funcionan y por qué son clave

Siguiente: RAG no es magia: el verdadero secreto de los chatbots con conocimiento →