Base de Datos Vectorial para RAG: pgvector vs Pinecone vs Qdrant (2026)

¿Qué base de datos vectorial elegir para tu RAG?

Una base de datos vectorial guarda tus embeddings y te devuelve las coincidencias más cercanas al momento de la consulta. Elige pgvector si ya corres Postgres y quieres joins SQL en un solo sistema; elige Pinecone si quieres un servicio administrado de cero operación y aceptas una factura SaaS; elige Qdrant si quieres búsqueda open-source y autohospedable, con filtrado fuerte por metadata y recuperación híbrida. En ~1M vectores el recall es prácticamente un empate, así que decide por operación y encaje, no por una fila de benchmark.

Este post es el compañero de “qué store” para el tutorial de cómo construir un sistema RAG con Claude. Ahí ves el pipeline completo; aquí decides dónde enchufas la pieza de “guardar y recuperar”. Y si todavía dudas si RAG es siquiera la herramienta correcta frente a fine-tuning, empieza por ahí y luego regresas a elegir el store.

Qué hace realmente una base de datos vectorial

Una base de datos vectorial guarda tus embeddings (vectores) junto con su metadata y hace búsqueda aproximada del vecino más cercano — ANN por sus siglas en inglés — para regresarte rápido los top-k vectores más parecidos a tu consulta. El índice más común para esto es HNSW. Es, literalmente, la capa de “guardar y recuperar” de un sistema RAG: nada más, nada menos.

El detalle que más gente confunde: la base vectorial está desacoplada del modelo de embeddings. Tú generas los vectores con un modelo — por ejemplo voyage-4 de Voyage, de 1024 dimensiones — y la base solo almacena esos números y hace matemática de similitud sobre ellos. El mismo store funciona con cualquier modelo de embeddings; cambiar de modelo no te obliga a cambiar de base. Por eso la decisión de “qué base” es independiente de la decisión de “qué modelo”.

Y una verdad que aplica a todas: cualquiera de estos motores soporta filtrado por metadata (tenant, fecha, fuente) junto con la búsqueda vectorial. Eso no es un lujo — es lo que vuelve seguro un RAG multi-tenant, donde cada cliente solo puede ver sus propios documentos.

pgvector: la extensión de Postgres

pgvector no es una base de datos aparte — es una extensión open-source de Postgres. Le agrega a Postgres un tipo de columna vector y dos índices ANN: HNSW e IVFFlat. La búsqueda por similitud se hace con operadores de distancia: <-> (L2), <=> (coseno) y <#> (producto interno). Un detalle práctico: como los vectores de voyage-4 vienen normalizados, el producto interno y el coseno ordenan igual, así que no te agobies eligiendo entre <=> y <#>.

La consulta base se ve así de simple:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE docs (
  id        bigserial PRIMARY KEY,
  content   text,
  tenant_id bigint,
  embedding vector(1024)
);

CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

-- top-5 chunks más parecidos, filtrando por tenant en la misma consulta
SELECT id, content
FROM docs
WHERE tenant_id = 42
ORDER BY embedding <=> $1
LIMIT 5;

La fuerza de pgvector es una sola: si ya corres Postgres, te quedas con una sola base de datos. Filas relacionales y vectores viven juntos, haces joins y filtros SQL reales en la misma consulta (como el WHERE tenant_id = 42 de arriba), tienes transacciones, y reusas tus backups, tu monitoreo y tus ops de siempre. Está listo para producción en 2026: plataformas de Postgres administrado como Supabase y Neon ya lo ofrecen listo.

El trade-off también es uno: tú lo ajustas y tú escalas Postgres. Los parámetros de HNSW (m, ef_construction, ef_search) los ajustas a mano según tu latencia y recall objetivo, y corpus muy grandes (100M+ vectores) piden un ajuste cuidadoso frente a motores dedicados. Si tu escala vive en el rango de “un Postgres decente aguanta”, pgvector suele ser la opción de menor complejidad total.

Pinecone: serverless totalmente administrado

Pinecone es una base de datos vectorial totalmente administrada y serverless — SaaS, no open source. La propuesta es cero operación: no corres servidores, escala sola y pagas por uso. Su arquitectura serverless (GA en 2024) reemplazó el modelo viejo de costo-por-pod, así que ya no dimensionas hardware a mano.

La fuerza es clara: montas RAG en producción sin operar infra y con buenos defaults de escalamiento. Si tu equipo no quiere (o no debe) dedicar a alguien a operar una base vectorial, esto te lo quita de encima. El trade-off es el de todo SaaS propietario: tus datos viven en la nube de Pinecone, dependes de un vendor cerrado, y la cuenta es por uso. No hay una opción de autohospedarlo el día que quieras salirte.

Qdrant: open-source en Rust

Qdrant es una base de datos vectorial open-source escrita en Rust. Trae buen rendimiento en un solo nodo, filtrado por metadata rico, cuantización, y búsqueda híbrida (densa + sparse) — o sea, combinar el vector denso con señales de keyword en una sola consulta. Lo corres de dos formas: autohospedado (Docker o binario) o con Qdrant Cloud, su versión administrada con tier gratuito.

docker run -p 6333:6333 qdrant/qdrant

La fuerza de Qdrant es que te da una alternativa open-source y autohospedable a Pinecone, con rendimiento fuerte y sin atarte a Postgres. Si pgvector no te queda porque no usas Postgres (o no quieres meterle vectores a tu base transaccional), Qdrant es el candidato natural. El trade-off: autohospedado, es un servicio más que operar — a menos que uses Qdrant Cloud y pagues por que ellos lo operen, con lo que vuelves al modelo de factura SaaS.

Menciones honrosas: Chroma y Weaviate

Dos más que vale la pena considerar sin clavarte:

Chroma tiene la mejor experiencia de desarrollo para prototipar: es Python-native, corre en memoria por default, y lo instalas en una línea. Su historia de producción mejoró, pero sigue siendo más ligera que Qdrant o Weaviate. Perfecto para el notebook donde validas la idea; para producción a escala, luego migras.

Weaviate trae búsqueda híbrida integrada fuerte de fábrica. Si tu caso depende mucho de combinar keyword denso + sparse y no quieres armarlo tú, entra a la conversación junto con Qdrant.

Estas dos son “también considéralas”, no la recomendación de default de este post.

Cómo elegir por escenario: el marco de decisión

Aquí está el marco completo, que es de verdad el corazón de la decisión. No lo pienses como “cuál es la mejor base”; piénsalo como “cuál encaja en mi contexto”.

Regla corta, para tenerla de memoria: ya en Postgres y quieres un solo sistema con filtros SQL, pgvector; quieres administrado sin operar infra y aceptas la factura SaaS, Pinecone; quieres rendimiento open-source autohospedable no atado a Postgres, Qdrant; prototipo local rápido, Chroma; híbrida densa+keyword lista de fábrica, Weaviate o Qdrant.

Costo y ops en la realidad: infra que ya pagas vs una factura SaaS

Aquí es donde la mayoría toma la decisión al revés, obsesionada con benchmarks de recall que en la práctica casi no separan a los candidatos. Repito el hecho incómodo: todos los motores mainstream llegan a ~95%+ de recall en ~1M vectores con HNSW por default. A ese tamaño, cualquiera funciona. Las diferencias reales se destapan en 10-100M de vectores, en la carga de ops, en la calidad del filtrado por metadata y en la búsqueda híbrida. El recall no decide.

Lo que sí decide es el modelo de costo, y se reduce a dos:

• Autohospedado (pgvector / Qdrant self-host): corre sobre infra que ya pagas. Si ya tienes un Postgres, pgvector es prácticamente costo marginal cero de infra nueva; pagas en tiempo de tu equipo ajustando y operando.
• Administrado (Pinecone / Qdrant Cloud): factura SaaS por uso. Pagas dinero en lugar de tiempo de ops. Para muchos equipos chicos eso es exactamente el trato correcto.

No te doy tablas de latencia ni de precios inventadas — los precios de los proveedores se mueven y dependen de tu carga. Verifica siempre contra los docs oficiales: pgvector en GitHub, pinecone.io y qdrant.tech. La decisión honesta es de quién opera la infra y quién paga la cuenta, no de quién gana un benchmark sintético.

Dónde encaja la base vectorial en tu pipeline de RAG

La base vectorial es una sola pieza del pipeline: guarda los embeddings y te devuelve los top-k al momento de la consulta. Antes de generar los embeddings, si tus documentos traen datos sensibles, limpia el PII antes de pasarlos al modelo, como explico en ocultar PII mexicano antes del LLM — porque lo que embebes, se queda embebido.

Más adelante en el pipeline, una vez que recuperas los fragmentos, los pasas al paso de generación con la API de Claude, y el contexto recuperado es un candidato ideal para prompt caching y bajar costos de tokens. Ese armado, hecho bien, es lo que te da un chatbot de IA sin alucinaciones porque el modelo responde apoyado en texto que puede ver.

Elige la base por tu contexto de infra y ops, no por el benchmark de moda. En la mayoría de los casos reales, la respuesta correcta es la más aburrida: si ya tienes Postgres, empieza con pgvector y solo pásate a un motor dedicado cuando tus evals — no tu FOMO — te demuestren que lo necesitas.