Cuando una empresa decide desplegar RAG (Retrieval-Augmented Generation) sobre su documentación corporativa, la primera pregunta técnica es: ¿dónde almacenamos los vectores? La respuesta no es neutra — la elección condicionará la latencia de las respuestas, los costes mensuales de infraestructura, la carga de mantenimiento y lo que será posible — o no — cuando el volumen de datos se duplique. En la práctica, los equipos recurren con más frecuencia a una de estas cuatro soluciones: pgvector, Qdrant, Weaviate y Milvus. Cada una tiene un enfoque distinto, fortalezas propias y un contexto en el que tiene sentido.
Este artículo no es un duelo de benchmarks (los benchmarks públicos disponibles dependen por naturaleza del hardware, la dimensionalidad y el patrón de carga). Es un marco de decisión — cómo elegir en función de lo que tu empresa realmente necesita.
Lo que tienen en común las cuatro soluciones
Las cuatro soluciones son capaces de realizar búsquedas approximate nearest neighbor (ANN) con índice HNSW, filtrado por metadatos e integración con los modelos de embeddings estándar. Todas son open-source (Apache 2.0 o equivalente) con opción de self-host o variante cloud gestionada. Una dimensionalidad de embedding habitual de 1 024 o 1 536 no supone ningún problema para ninguna de ellas.
La diferencia empieza cuando te enfrentas a la escala, los requisitos de consistencia, la infraestructura existente o la necesidad de búsqueda híbrida (vector + keyword). Ahí es donde los cuatro caminos se bifurcan.
pgvector — cuando ya tienes Postgres
pgvector es una extensión de PostgreSQL. No existe como base de datos independiente — se ejecuta dentro de tu instancia PG existente. Este es a la vez su argumento más sólido y su principal limitación.
Cuándo tiene sentido:
Si tu empresa ya opera PostgreSQL y el volumen de vectores no supera el orden de decenas de millones, pgvector es una opción de producción legítima. La ventaja es fundamental: los vectores, los datos estructurados y los metadatos viven en una única base de datos, bajo una misma transacción, con un único proceso de backup. No es necesario sincronizar dos sistemas ni ampliar la infraestructura.
La versión de pgvector de principios de 2026 añadió soporte para vectores dispersos (sparse) y mejoró notablemente el rendimiento del índice IVFFlat. Con índice HNSW y una configuración adecuada, una base de datos en un servidor estándar aguanta de 5 000 a 15 000 QPS en una colección de unos 10 millones de vectores con dimensión 1 024. Para la gran mayoría de despliegues RAG B2B sobre documentación interna, eso es suficiente.
Dónde tiene límites:
Con colecciones que superan los 50 millones de vectores, PG empieza a chocar con las características propias de su arquitectura — un rowstore optimizado para cargas transaccionales, no para throughput pure-ANN. El rendimiento cae y escalar exige o bien sharding o bien migrar a otra solución. Otro límite: pgvector no dispone de búsqueda híbrida nativa — combinar búsqueda vectorial y keyword requiere construir el pipeline manualmente, por ejemplo mediante tsvector y un RRF (Reciprocal Rank Fusion) artesanal.
Perfil típico del proyecto: base de conocimiento interna o soporte al cliente, colección de 1–5 millones de vectores, equipo que gestiona Postgres existente y prefiere no ampliar la infraestructura.
Qdrant — rendimiento y self-host en nodo único
Qdrant es una base de datos construida desde cero para la búsqueda vectorial. Escrita en Rust, con énfasis en el rendimiento y el despliegue self-host sencillo — binario o contenedor Docker, sin dependencias externas.
La característica clave que distingue a Qdrant en 2026: soporte nativo para multi-vector estilo ColBERT (late interaction), es decir, la posibilidad de almacenar varios vectores por documento y buscar a través de su interacción. Esto permite un retrieval de última generación sin necesidad de un servidor reranker independiente — Qdrant gestiona la late interaction directamente en el índice. Para proyectos donde la precisión importa y no se quiere construir un servicio reranker aparte, esta es una ventaja significativa.
Características de rendimiento: con 10 millones de vectores, 1 024 dimensiones y una carga de aproximadamente 1 000 QPS, la latencia P99 ronda los 12 ms. Escala bien hasta cientos de millones de vectores en un nodo único con RAM suficiente, o mediante el servicio gestionado Qdrant Cloud para instalaciones mayores.
Búsqueda híbrida: Qdrant soporta vectores dispersos (estilo BM25) como característica de primera clase — el vector denso y el vector disperso se buscan en un único paso, sin mezclar resultados manualmente. Para el escenario RAG enterprise típico (documentación técnica, catálogos de producto, manuales de servicio), esto es ideal: las palabras clave exactas (números de referencia, códigos, términos específicos) las captura la rama dispersa, y la semántica la captura la rama densa.
Cuándo tiene sentido:
El equipo quiere una solución self-host, latencia predecible, búsqueda híbrida nativa y no quiere gestionar un clúster distribuido. La colección puede ir desde millones hasta cientos de millones de vectores. Los operadores con una sola persona en infra prefieren el despliegue sencillo.
Dónde tiene límites:
Para colecciones realmente grandes (miles de millones de vectores), la distribución nativa es más limitada que la de Milvus. El ecosistema de conectores de integración es más reducido que el de Weaviate.
Weaviate — búsqueda híbrida modular
Weaviate tiene una filosofía distinta a la de Qdrant: cada capacidad es un módulo — generación de embeddings, indexación keyword, reranking, input multimodal. Esto resta simplicidad, pero aporta una gran flexibilidad sin necesidad de código personalizado.
Característica clave: búsqueda híbrida nativa (BM25 + vector denso + filtro de metadatos) como ciudadano de primera clase en la API de consultas. El índice BM25 y el índice vectorial están integrados en un único planificador de consultas con fusión RRF automática. Weaviate también destaca por una rica API GraphQL para consultas, algo que valoran los equipos que necesitan filtrado complejo (multi-tenant, derechos de acceso, metadatos jerárquicos).
Rendimiento: orientativamente entre 25 000 y 50 000 QPS con 10 millones de vectores y latencia P99 en torno a los 16 ms. Los costes de la variante cloud (Weaviate Cloud) son superiores a los de Qdrant, pero el equipo obtiene reranking gestionado, monitorización y SLA.
Cuándo tiene sentido:
Despliegue multi-tenant (varios clientes o departamentos en una misma instancia con datos aislados), necesidad de filtrado avanzado, equipo que valora el servicio gestionado con un ecosistema más rico. También es una buena elección para proyectos con contenido multimodal, donde el módulo de embedding de imágenes de Weaviate ahorra código personalizado.
Dónde tiene límites:
La arquitectura modular añade complejidad operativa — más configuraciones, más puntos de fallo. Para un caso de uso RAG simple, Weaviate es over-engineered. El enfoque schema-first (definir los tipos antes de indexar) puede ralentizar el prototipado.
Milvus — escala extrema
Milvus es distributed-first desde la primera línea de código. Se ejecuta sobre Kubernetes, con etcd para la coordinación, almacenamiento compatible con S3 para la persistencia y componentes separados para ingestion, indexación y consultas. Esta arquitectura supone una sobrecarga para proyectos pequeños — y una ventaja para los grandes.
Con colecciones de miles de millones de vectores, Milvus alcanza un throughput de 100 000+ QPS con escalado horizontal. La búsqueda ANN acelerada por GPU reduce aún más la latencia con índices grandes. La versión gestionada — Zilliz Cloud — absorbe la carga operativa.
Cuándo tiene sentido:
Colecciones de más de 100 millones de vectores, carga de alta frecuencia (personalización en e-commerce, sistemas de recomendación, búsqueda vectorial en catálogos de miles de millones de ítems), equipo con capacidad DevOps para operar un stack Kubernetes.
Dónde tiene límites:
Para un RAG enterprise estándar con millones de vectores, Milvus es una sobrecarga innecesaria. La instalación mínima de producción requiere varios componentes — clúster etcd, MinIO/S3, query nodes, data nodes. Para un equipo de una sola persona, es demasiada infraestructura que mantener. La búsqueda híbrida existe, pero es menos fluida que en Qdrant o Weaviate.
Marco de decisión: tres preguntas antes de elegir
En lugar de una comparativa en tabla (donde cada celda requiere contexto), recomendamos responder tres preguntas en orden:
1. ¿Cuál es el tamaño de la colección ahora y en 2 años?
- Hasta 5 millones de vectores y Postgres existente → prueba
pgvectorprimero. Evitarás nueva infraestructura. - De 5 millones hasta cientos de millones →
QdrantoWeaviatesegún los criterios siguientes. - Miles de millones de vectores o 100 000+ QPS →
Milvus/ Zilliz Cloud.
2. ¿Cuántas personas gestionan la infraestructura?
- Un desarrollador o equipo pequeño →
Qdrant(self-host sencillo, binario/Docker, dependencias mínimas). - Equipo con capacidad DevOps que prefiere servicio gestionado →
Weaviate CloudoZilliz Cloud. - Equipo nativo en Kubernetes con experiencia en sistemas distribuidos →
Milvus.
3. ¿Cuál es la estructura de las consultas?
- Búsqueda semántica pura → cualquiera de estas DB.
- Híbrida (precisión keyword + semántica) →
Qdrant(sparse + dense nativo) oWeaviate(BM25 + dense nativo). Si usaspgvector, el híbrido hay que construirlo a mano. - Multi-tenant con datos aislados, filtrado complejo →
Weaviatetiene el planificador de consultas más avanzado. - ColBERT / multi-vector late interaction →
Qdranten 2026 como el único de los cuatro que lo soporta de forma nativa.
Cifras de rendimiento en contexto
Los benchmarks públicos disponibles (como ann-benchmarks.com y otras comparativas públicas) muestran orientativamente:
Con una carga de aproximadamente 1 000 QPS en una colección de 10 millones de vectores con 1 024 dimensiones:
pgvector: 5 000–15 000 QPS máximo, latencia P99 variable según el hardwareQdrant: 30 000–80 000 QPS, P99 en torno a 12 msWeaviate: 25 000–50 000 QPS, P99 en torno a 16 msMilvus: 100 000+ QPS con escalado horizontal, P99 en torno a 18 ms (configuración distribuida)
Estas cifras son orientativas — los resultados reales dependen de la dimensionalidad de los vectores, la estrategia de indexación (parámetros HNSW), el hardware (memoria, CPU/GPU), el patrón de carga y si se trata de una carga single-tenant o multi-tenant. Un benchmark de otro proyecto es solo un punto de partida para tus propias mediciones.
Los costes mensuales de las variantes cloud gestionadas se sitúan, para una carga RAG enterprise típica (10 millones de vectores, ~1 000 QPS), en el orden de varios miles de euros — con diferencias notables según el proveedor y la región. El self-host en servidor propio reduce el coste variable, pero añade costes fijos de operación.
Donde pgvector sorprende positivamente
Uno de los mitos más frecuentes en el entorno de empresas SK/EU: «pgvector es solo una solución transitoria para el PoC». En la práctica no es así. Hemos visto en clientes de manufactura y logística despliegues RAG sobre 2–3 millones de vectores funcionando en producción sobre pgvector sin problemas, donde la única motivación era el clúster PostgreSQL existente y un equipo sin ancho de banda para nueva infraestructura.
Lo que es clave para un buen rendimiento de pgvector en producción: índice HNSW (no IVFFlat), configuración correcta de maintenance_work_mem para la construcción del índice, y particionado si la colección crece. Con estos ajustes, pgvector gestiona la mayoría de los escenarios RAG enterprise internos sin necesidad de migrar.
Donde pgvector realmente no es suficiente: búsqueda híbrida avanzada, retrieval multi-vector / ColBERT, y colecciones en decenas de millones donde el rendimiento de la capa de retrieval es crítico para el UX (latencia sub-20 ms).
Integración con frameworks RAG
Las cuatro bases de datos tienen integración de primera clase en LlamaIndex y LangChain. LlamaIndex dispone de QdrantVectorStore, WeaviateVectorStore, PGVectorStore y MilvusVectorStore nativos con una interfaz consistente — lo que significa que migrar entre bases de datos es un refactor de una sola línea de configuración, no de todo el pipeline.
Para la elección del framework y la evaluación de la calidad del pipeline RAG, te remitimos a RAG pipeline — 3 ajustes de calidad — donde se analizan en detalle las estrategias de chunking, la actualización del modelo de embeddings y el reranking, que son independientes de la elección de la base de datos vectorial.
El modelo de embeddings es una decisión aparte — para elegirlo, consulta Cómo elegir un modelo de embeddings; para la combinación de BM25 y vectores en búsqueda híbrida, Búsqueda híbrida (BM25 + vectores + reranking).
Preguntas frecuentes
¿Puedo empezar con pgvector y migrar a Qdrant más adelante?
Sí, y es un patrón habitual. La abstracción del vector store en LlamaIndex es una capa suficientemente delgada — la migración requiere reingestar los vectores (reindexar los documentos) y cambiar la configuración del store. La lógica del pipeline, el chunking y el modelo de embeddings permanecen sin cambios. Siempre que almacenes los textos originales y los metadatos en una base de datos relacional, la reingestión es en la mayoría de los casos un script, no meses de trabajo.
¿Es Qdrant realmente más rápido que Weaviate para mi carga?
Depende del patrón de carga. Qdrant muestra ventaja en escenarios single-tenant con consultas uniformes. Weaviate puede ser comparativamente mejor en filtrado multi-tenant complejo, donde su planificador de consultas optimiza la intersección del filtro vectorial y keyword. Recomendamos ejecutar tu propio benchmark sobre una muestra representativa de tus datos — 1 hora de medición sobre tu propio corpus vale más que cualquier benchmark público.
¿Necesitamos Milvus si tenemos 50 millones de vectores?
Probablemente no. Qdrant y Weaviate gestionan cientos de millones de vectores en un servidor single-node bien configurado. Milvus se justifica con colecciones de miles de millones de vectores o cuando se necesitan 100 000+ QPS, donde la arquitectura distribuida aporta un ahorro real. Para 50 millones de vectores, Milvus es más sobrecarga que solución.
¿Afecta la elección de la base de datos vectorial a la calidad de las respuestas RAG?
Directamente, poco — la calidad de las respuestas depende principalmente de la calidad del chunking, el modelo de embeddings y el reranker, no de qué base de datos almacena los vectores. Indirectamente, sí: si la base de datos vectorial tiene alta latencia o bajo recall en búsquedas filtradas, el modelo generativo recibirá fragmentos de contexto de peor calidad. La elección de la DB afecta sobre todo al rendimiento, el coste y la carga operativa — no a la lógica del pipeline de retrieval en sí.
¿Funciona pgvector también para texto en español?
Sí — una base de datos vectorial es agnóstica al idioma. Almacena y busca vectores independientemente de la lengua. Las propiedades lingüísticas son responsabilidad del modelo de embeddings, no de la DB. Para español recomendamos modelos multilingües como BGE-M3 o Qwen3-Embedding — más información en el artículo Cómo elegir un modelo de embeddings.
*MP Industrial Solutions ayuda a las empresas a diseñar y desplegar una infraestructura RAG adecuada a su carga real — desde evaluar si pgvector es suficiente hasta el despliegue en producción de Qdrant o Weaviate en servidores on-prem. Si estás valorando un despliegue nuevo o tienes problemas de rendimiento en tu capa vectorial actual, estaremos encantados de mantener una primera llamada sin compromiso.*