Definición
Una vector database (base de datos vectorial, o vector store) es una base de datos especializada en almacenar y consultar vectores de embeddings de alta dimensionalidad mediante búsqueda por similitud. Es la pieza fundamental del stack moderno de RAG, búsqueda semántica, recomendación y cualquier sistema donde la pregunta "¿qué se parece a esto?" sea más útil que "¿qué es exactamente igual a esto?".
Las bases tradicionales (PostgreSQL, MySQL) están optimizadas para búsquedas exactas o por rango sobre datos estructurados. Las vector DBs están optimizadas para encontrar los K vectores más cercanos (top-K) a un vector de consulta en un espacio de 384-4096 dimensiones, sobre colecciones de millones o miles de millones de vectores, en milisegundos.
A 2026 el ecosistema está maduro: Pinecone (SaaS pionero), Qdrant, Weaviate, Milvus, Chroma (open source), pgvector (extensión de PostgreSQL), y motores integrados en cloud (OpenAI Vector Store, Vertex AI Matching Engine).
Cómo funciona
El reto técnico central: encontrar los K vectores más cercanos en un espacio de alta dimensionalidad es computacionalmente caro. Búsqueda exhaustiva (comparar contra todos) escala linealmente — inviable a millones de vectores.
La solución: Approximate Nearest Neighbors (ANN) — algoritmos que sacrifican un poco de precisión por velocidad masiva:
-
HNSW (Hierarchical Navigable Small World): el más usado hoy. Construye un grafo jerárquico donde cada vector está conectado a sus vecinos. Búsqueda navega el grafo desde el nivel superior hacia abajo. Recall típico >95%, tiempos sub-milisegundo.
-
IVF (Inverted File Index): agrupa vectores en clusters (centroides), busca primero el cluster correcto, luego dentro. Usado por Faiss/Milvus.
-
LSH (Locality-Sensitive Hashing): hash que pone vectores similares en el mismo bucket. Más simple, menos preciso, en desuso.
-
PQ (Product Quantization): cuantiza vectores para ahorrar memoria masiva. Se combina con IVF.
-
DiskANN: optimizado para conjuntos masivos que no caben en RAM (sirve desde SSD).
En la práctica, HNSW domina el mercado por su balance entre velocidad, precisión y simplicidad.
Métricas de distancia
Tres principales para comparar vectores:
- Cosine similarity: ángulo entre vectores. Ignora magnitud. Lo más usado en embeddings de texto.
- Dot product: producto escalar. Equivalente a coseno si vectores normalizados.
- Euclidean distance (L2): distancia "física" en el espacio. Sensible a magnitud.
La mayoría de embeddings de texto modernos vienen normalizados → coseno y dot product son equivalentes y más eficientes computacionalmente.
Ejemplo práctico
En antonioecheverria.es la búsqueda semántica del diccionario usa una versión muy simplificada de vector DB (un JSON estático con vectores precomputados + cosine similarity en cliente). Para 65 términos basta. Pero si creciéramos a 50.000 términos + comentarios de usuarios + chunks de blog, ya necesitaríamos una vector DB real.
Para AE Works desarrollamos un asistente RAG sobre 200.000 documentos de un cliente del sector legal:
-
Indexación:
- Cada documento se chunkea en piezas de ~500 tokens (overlap 50).
- Cada chunk se embebe con un modelo apropiado (~1.500 dimensiones).
- Se guarda en Qdrant con metadatos: cliente_id, tipo_documento, fecha, jurisdicción.
-
Búsqueda:
- Query del usuario → embedding del query.
- Qdrant devuelve top-50 chunks más cercanos (con filtro de cliente_id y fecha).
- Re-ranker (Cohere) reordena los 50 a top-10 por relevancia real.
- El LLM recibe esos 10 chunks como contexto.
Volumen: ~3M de chunks indexados, 1.500 dimensiones. Qdrant los maneja con HNSW en ~80GB de RAM. Latencia de búsqueda: 20-50ms.
Sin vector DB, esa búsqueda sería imposible a esa escala con latencia razonable.
Comparativa de opciones populares
| Solución | Tipo | Cuándo elegirla |
|---|---|---|
| Pinecone | SaaS gestionado | Quieres simplicidad operacional, eres equipo pequeño |
| Qdrant | Open source + SaaS | Rendimiento alto, autohospedable, buen DX |
| Weaviate | Open source + SaaS | Funcionalidades avanzadas (hybrid search, modules) |
| Milvus | Open source + SaaS | Escala enterprise, billions de vectores |
| Chroma | Open source | Prototipo / desarrollo local, simple |
| pgvector | Extensión PostgreSQL | Ya tienes PostgreSQL, volumen mediano (<10M vectores) |
| OpenAI Vector Store | Gestionado en OpenAI | Tu stack es 100% OpenAI |
| MongoDB Atlas Vector Search | Gestionado | Ya usas MongoDB |
| Redis Stack | Gestionado / open source | Búsqueda vectorial + caché en mismo sistema |
Para la mayoría de proyectos nuevos a 2026 las elecciones razonables son: Qdrant (autohospedado/managed) si quieres open source con buen rendimiento, Pinecone si quieres mínimo overhead operacional, pgvector si ya tienes PostgreSQL y el volumen es manejable.
Features modernas más allá de la búsqueda básica
Las vector DBs serias hoy ofrecen mucho más que "top-K más cercanos":
- Filtros con metadatos: combinar similitud vectorial con WHERE típico de SQL (categoría, fecha, cliente, etc.). Imprescindible en producción.
- Hybrid search: combinar búsqueda densa (embeddings) con búsqueda léxica (BM25) para mejor recall.
- Multi-tenancy: aislamiento de datos por cliente / namespace.
- Re-ranking integrado: algunos motores hacen el re-ranking en el server, no hay que sacar los datos.
- Sparse + Dense vectors: combinar SPLADE u otros sparse con embeddings densos.
- CRUD eficiente: insert, update, delete con re-indexación incremental.
- Snapshots y replicación: backup, alta disponibilidad.
- API streaming: para grandes datasets que se procesan en batches.
Errores comunes al usar vector DBs
- Pensar que son intercambiables con bases tradicionales: una vector DB no sustituye a Postgres. Coexisten.
- No usar filtros con metadatos: buscar entre los 200.000 documentos del cliente Y los del cliente B en cada consulta es lento y peligroso.
- Embeddings de modelos distintos en la misma colección: incompatibles. Cada espacio vectorial es independiente.
- Reindexar todo cuando cambia un documento: las vector DBs modernas soportan updates incrementales. Úsalos.
- Subestimar el coste de embeddings: generar embeddings de 1M chunks puede costar 50-500€ en APIs.
- No medir recall@K: si tu top-10 no contiene lo relevante, ningún re-ranker lo va a arreglar. Mide.
- Confundir "vector DB" con "RAG": la vector DB es UN componente del RAG, no el sistema completo.
Cuándo usar una vector DB
Sí, una vector DB tiene sentido cuando:
- Construyes RAG sobre cualquier volumen > unas pocas docenas de documentos.
- Necesitas búsqueda semántica (intención, no palabras exactas).
- Tienes recomendación basada en similitud.
- Detectas duplicados o variantes de contenido.
- Tu corpus es dinámico y necesitas updates eficientes.
No es necesaria cuando:
- Tu volumen es trivial (<200 documentos) → JSON estático + cosine in-memory basta.
- Solo necesitas búsqueda léxica (Pagefind, Elasticsearch text, Postgres FTS).
- El caso es transaccional/estructurado puro.
Referencias
- Malkov & Yashunin · HNSW paper — el algoritmo que domina las vector DBs modernas
- Qdrant Benchmarks — comparativa imparcial de motores de búsqueda vectorial
- pgvector Documentation — la extensión que llevó capacidad vectorial a PostgreSQL