Todo proyecto de generación aumentada por recuperación acaba preguntándose: ¿qué base de datos vectorial? El mercado está abarrotado: motores dedicados como Qdrant, Weaviate y Milvus, servicios gestionados como Pinecone y extensiones vectoriales para bases de datos que ya usas, sobre todo pgvector para PostgreSQL. Los benchmarks publicados por los proveedores rara vez se parecen a tu carga de trabajo. Esta guía explica qué diferencia realmente a las opciones, qué preguntas deciden la elección y por qué, en muchos proyectos de negocio, la respuesta es "el PostgreSQL que ya tienes".

Qué hace una base de datos vectorial

Una base de datos vectorial guarda embeddings —arrays de números que representan el significado de un texto, una imagen u otros datos— y responde a la consulta "encuentra los k vectores más parecidos a este". La búsqueda exacta compara la consulta con cada vector; está bien para decenas de miles de elementos, pero es demasiado lenta para millones. Los sistemas de producción usan índices de vecinos más cercanos aproximados (ANN) que sacrifican un poco de recall a cambio de una velocidad órdenes de magnitud mayor.

Además de ese núcleo, un almacén vectorial de producción necesita:

  • Filtrado por metadatos: "documentos parecidos, pero solo del cliente 42, en idioma es y actualizados después del 2026-01-01".
  • Búsqueda híbrida: combinar la similitud vectorial con la relevancia por palabras clave (BM25).
  • CRUD y consistencia: actualizar y borrar documentos sin reconstruir el índice.
  • Operaciones: copias de seguridad, replicación, monitorización, control de acceso.

Cómo funcionan los índices ANN, en breve

HNSW (Hierarchical Navigable Small World) construye un grafo de varias capas en el que cada vector se enlaza con sus vecinos; la búsqueda empieza en una capa superior dispersa y va descendiendo (Malkov y Yashunin, 2016). Ofrece un recall y una latencia excelentes y admite inserciones incrementales, a costa de memoria: el grafo vive en RAM junto a los vectores. Parámetros clave: m (enlaces por nodo), ef_construction (calidad de construcción) y ef_search (compromiso entre recall y velocidad en la consulta).

IVF (inverted file) agrupa los vectores en clústeres y busca solo en los más cercanos. Se construye más rápido y usa menos memoria, pero el recall depende de cuántos clústeres se exploren y necesita reentrenarse a medida que cambian los datos.

La cuantización comprime los vectores —escalar (float32 → int8), cuantización de producto o binaria—, reduciendo la memoria entre 4 y 32 veces con cierto coste de recall, que normalmente se recupera volviendo a puntuar los mejores candidatos con los vectores completos. Los índices de estilo DiskANN mantienen la mayoría de los datos en SSD para colecciones muy grandes.

En ann-benchmarks.com se publican comparativas independientes de algoritmos ANN. La lección práctica: para el rendimiento de búsqueda en bruto, la elección del índice y sus parámetros importan más que la marca de la base de datos.

Los candidatos

Opción Tipo Puntos fuertes A vigilar
pgvector Extensión de PostgreSQL Una sola base de datos, joins SQL, transacciones, copias de seguridad y herramientas existentes; HNSW e IVFFlat Las colecciones muy grandes y la búsqueda con mucho filtrado requieren ajuste; planificar vacuum y memoria
Qdrant Motor dedicado (Rust), OSS + nube Filtrado potente integrado en HNSW, cuantización, vectores dispersos para búsqueda híbrida Otro sistema que operar
Weaviate Motor dedicado (Go), OSS + nube Búsqueda híbrida integrada, módulos de vectorización, multitenencia Más consumo de memoria; esquema con opiniones propias
Milvus Motor distribuido, OSS + nube de Zilliz Miles de millones de vectores, muchos tipos de índice, incluidos GPU y DiskANN Complejidad operativa de un sistema distribuido
Pinecone SaaS totalmente gestionado Sin operaciones, precios serverless, buena experiencia de desarrollo Dependencia del proveedor, residencia de datos, coste a escala
Elasticsearch / OpenSearch Motores de búsqueda con soporte vectorial BM25 maduro más vectores en un solo sitio Consumen muchos recursos; las funciones vectoriales varían según la versión

Todos son lo bastante buenos para cargas RAG típicas. La decisión depende sobre todo de las operaciones, la escala y la gobernanza de los datos.

Las preguntas que deciden la elección

1. ¿Cuántos vectores, de verdad?

Haz una estimación honesta. Una base de conocimiento de empresa con 20.000 documentos divididos en 200.000 fragmentos de 1.024 dimensiones son unos 800 MB de vectores float32: caben con holgura en una instancia de PostgreSQL. Diez millones de fragmentos son unos 40 GB antes de la sobrecarga del índice, lo que cambia el panorama. De cientos de millones a miles de millones hace falta un motor dedicado y distribuido o una cuantización agresiva.

2. ¿Cuánto importa el filtrado?

El SaaS multicliente, los documentos con control de acceso y la búsqueda en catálogos dependen de los filtros. El enfoque ingenuo de "buscar y luego filtrar" se rompe cuando el filtro es selectivo: pides los 10 mejores, el ANN devuelve 10 vecinos y 9 pertenecen a otros clientes. Los motores difieren en cómo combinan el filtrado con el índice. Qdrant y Weaviate integran los filtros en el recorrido del grafo; pgvector admite escaneos iterativos del índice en las versiones recientes, además de índices parciales o particionado por cliente. Prueba con la selectividad real de tus filtros.

3. ¿Necesitas búsqueda híbrida?

En documentos de empresa —códigos de producto, números de artículos legales, nombres, mensajes de error—, la búsqueda vectorial pura no encuentra las coincidencias exactas. La búsqueda híbrida con BM25 más vectores, fusionados con reciprocal rank fusion (Cormack et al., 2009), es la opción por defecto que recomiendo; consulta RAG para empresas. Weaviate, Qdrant (vectores dispersos), Elasticsearch y OpenSearch la admiten de forma nativa; en PostgreSQL, combina pgvector con la búsqueda de texto completo en una sola consulta SQL.

4. ¿Quién lo opera?

Un motor dedicado es otro sistema con estado: copias de seguridad, actualizaciones, monitorización, parches de seguridad, planificación de capacidad. Si tu equipo ya opera bien PostgreSQL —con copias de seguridad y recuperación ante desastres probadas—, añadir pgvector no cuesta casi nada en operaciones. Un servicio gestionado elimina las operaciones, pero añade un proveedor, una factura que crece con los datos y cuestiones de residencia de datos; consulta privacidad en aplicaciones LLM.

5. ¿Cómo cambian los datos?

Los datos que se actualizan con frecuencia (precios, stock, tickets) necesitan upserts y borrados eficientes. HNSW gestiona bien las inserciones; en algunos motores, los borrados dejan marcas que requieren limpieza periódica o reindexación. Volver a vectorizarlo todo al cambiar de modelo de embeddings es una migración planificada en cualquier sistema: conserva el texto en bruto para poder volver a vectorizar.

Búsqueda híbrida en PostgreSQL

Un ejemplo compacto que combina pgvector y búsqueda de texto completo con reciprocal rank fusion:

-- Schema
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE chunks (
  id bigserial PRIMARY KEY,
  tenant_id int NOT NULL,
  content text NOT NULL,
  tsv tsvector GENERATED ALWAYS AS (to_tsvector('spanish', content)) STORED,
  embedding vector(1024) NOT NULL
);
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);
CREATE INDEX ON chunks USING gin (tsv);
CREATE INDEX ON chunks (tenant_id);

-- Query: $1 = query embedding, $2 = query text, $3 = tenant
WITH vec AS (
  SELECT id, row_number() OVER (ORDER BY embedding <=> $1) AS r
  FROM chunks WHERE tenant_id = $3
  ORDER BY embedding <=> $1 LIMIT 50
), kw AS (
  SELECT id, row_number() OVER (ORDER BY ts_rank(tsv, q) DESC) AS r
  FROM chunks, plainto_tsquery('spanish', $2) q
  WHERE tenant_id = $3 AND tsv @@ q
  ORDER BY ts_rank(tsv, q) DESC LIMIT 50
)
SELECT c.id, c.content,
       COALESCE(1.0 / (60 + vec.r), 0) + COALESCE(1.0 / (60 + kw.r), 0) AS score
FROM chunks c
LEFT JOIN vec ON vec.id = c.id
LEFT JOIN kw  ON kw.id  = c.id
WHERE vec.id IS NOT NULL OR kw.id IS NOT NULL
ORDER BY score DESC
LIMIT 10;

La configuración de texto 'spanish' aplica el stemming del español que trae PostgreSQL; si tus documentos mezclan idiomas, valora 'simple' (sin stemming) o una columna tsvector por idioma, y para necesidades avanzadas un motor de búsqueda. Ajusta hnsw.ef_search por consulta según el recall que necesites.

Benchmarks para tu carga de trabajo

Los benchmarks de los proveedores están optimizados para el proveedor. Haz los tuyos, pequeños pero realistas:

  1. Toma de 100 a 500 consultas reales con documentos relevantes conocidos (tu conjunto de evals).
  2. Carga tus datos reales con tu modelo de embeddings real y tus metadatos.
  3. Mide el recall@k frente a la búsqueda exacta, la latencia p95 con filtros, la memoria y el tiempo de construcción del índice.
  4. Prueba las actualizaciones: inserta y borra el 10% de los datos y vuelve a medir.
  5. Estima el coste mensual, incluidas las réplicas y las copias de seguridad.

La mayoría de los equipos descubren que las diferencias en la calidad RAG de extremo a extremo vienen del chunking, los embeddings, la búsqueda híbrida y el reranking, no de la base de datos. Consulta embeddings y chunking.

Mis recomendaciones por defecto

  • Hasta unos 5–10 millones de vectores, con PostgreSQL ya en el stack: pgvector con HNSW y búsqueda híbrida en SQL. Las operaciones más sencillas y consistencia transaccional con tus datos de negocio.
  • Mucho filtrado, multicliente a escala o necesidad de cuantización avanzada: Qdrant o Weaviate, autoalojados en Kubernetes o en su nube gestionada.
  • Cientos de millones de vectores o búsqueda acelerada por GPU: Milvus/Zilliz.
  • Sin capacidad operativa y sin restricciones de residencia de datos: Pinecone u otro servicio gestionado.

Elijas lo que elijas, conserva el texto en bruto y los metadatos como fuente de verdad y trata el índice vectorial como un derivado que se puede reconstruir.

Preguntas frecuentes

¿pgvector está "listo para producción"? Sí, para la escala que necesitan la mayoría de las aplicaciones de negocio. Planifica la memoria de los índices HNSW, ajusta maintenance_work_mem para las construcciones y monitoriza el vacuum.

¿Deberíamos guardar los vectores junto a los datos de negocio? A menudo sí: simplifica el control de acceso y los joins, y mantiene coherentes los borrados (el derecho de supresión del RGPD también debe eliminar los vectores).

¿Cuántas dimensiones deberíamos usar? Las fija el modelo de embeddings. Los modelos con entrenamiento de estilo Matryoshka permiten truncar dimensiones para ahorrar memoria con una pequeña pérdida de calidad.

¿Podemos cambiar de base de datos más adelante? Sí, si tu capa de recuperación está detrás de una interfaz fina y conservas el texto en bruto para reindexar.

Fuentes

  1. Malkov, Y., Yashunin, D. (2016). Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs.
  2. pgvector en GitHub.
  3. Documentación de Qdrant, Weaviate, documentación de Milvus, documentación de Pinecone.
  4. ANN-Benchmarks.
  5. Cormack, G., Clarke, C., Buettcher, S. (2009). Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods.
  6. Douze et al. (2024). The Faiss library.