Pinecone vs Qdrant vs Weaviate vs Milvus vs pgvector: Comparativa Completa de Bases de Datos Vectoriales en 2026

A fecha de agosto de 2026, lo que determina de verdad la calidad de una canalización RAG (generación aumentada por recuperación) o de un agente de IA no es el modelo, sino la capa de recuperación. Da igual lo bueno que sea el LLM que conectes: si no encuentra los documentos que sirven de evidencia, la respuesta se derrumba. Por eso la comparativa de bases de datos vectoriales en 2026 ha dejado de girar en torno a “cuál es más rápida” para plantear otra pregunta: “cuál encaja con dónde vive nuestra información, con el personal de operaciones que tenemos y con nuestras necesidades de búsqueda híbrida”. Esta guía práctica analiza Pinecone, Qdrant, Weaviate, Milvus (Zilliz) y pgvector basándose única y exclusivamente en documentación y páginas de precios oficiales.

El momento, además, es peculiar. Milvus 3.0 se anunció el 27 de julio de 2026 y recibió su etiqueta de release el 29 de julio. Cuando escribimos esto no ha pasado ni una semana, y su concepto es “Lake-Native”: consultar directamente las tablas Parquet, Iceberg, Lance o Vortex que ya están almacenadas en tu object storage sin copiarlas a la base de datos vectorial. Para cualquier organización que ya opere un data lake, esto elimina de raíz la premisa de “primero hay que construir una canalización de ingesta”.

En esas mismas fechas, en el terreno de pgvector hubo una noticia bastante más urgente. CVE-2026-3172: una vulnerabilidad de desbordamiento de búfer provocada por un wraparound de enteros durante la construcción paralela de índices HNSW, que afecta a todas las versiones desde la 0.6.0 hasta la 0.8.1 y que se corrigió en la 0.8.2. Y aunque varios blogs hablan de “pgvector 0.9”, la 0.9 no existe. A 2 de agosto de 2026 la última versión es la 0.8.6 (2026-07-29). En este artículo iremos corrigiendo, uno por uno, estos datos mal difundidos con las cifras oficiales.

A continuación empezamos con la tabla comparativa global de los cinco productos y seguimos, por orden, con un análisis en profundidad de cada uno, cómo tratar el rendimiento con honestidad, la comparativa completa de tarifas oficiales, recomendaciones por perfil de usuario, consejos prácticos con errores frecuentes y una sección de preguntas frecuentes. En lugar de encadenar cifras de benchmarks que suenan convincentes, vamos a poner números solo donde están verificados y decir claramente cuándo no lo están. Porque eso es lo que de verdad sirve a la hora de tomar una decisión de adopción.

1. Resumen ejecutivo: las 5 grandes bases de datos vectoriales de un vistazo (agosto de 2026)

Para ingenieros de IA y responsables técnicos con poco tiempo, aquí está condensada en una sola tabla la filosofía de diseño, la versión más reciente, la estructura de precios, el plan gratuito y los pros y contras de cada uno de los cinco productos.

📊 Tabla comparativa global de las 5 grandes BD vectoriales (agosto de 2026)

Lo primero que debería saltar a la vista en esta tabla es la última fila. Más que productos rivales, los cinco son opciones que responden a situaciones organizativas distintas. Si ya usas Postgres y manejas menos de diez millones de vectores, pgvector es prácticamente la opción por defecto, y adoptar una base de datos vectorial dedicada significa crearte tú mismo un coste nuevo: personal de operaciones y una canalización de sincronización.

2. Análisis en profundidad de las 5 grandes bases de datos vectoriales

🌲 1) Pinecone: la referencia del serverless totalmente gestionado

• Serverless como opción por defecto absoluta: los antiguos índices basados en pods han quedado como legado y hoy el camino estándar es serverless. No tener que preocuparse por el dimensionado de nodos, el sharding o el rebalanceo es la razón de ser de Pinecone. Para un equipo sin ingenieros de infraestructura, esa sola línea pesa más que todos los demás criterios de comparación juntos.
• Los tres tipos de índice, todos en serverless: admite los tres tipos —dense / sparse / full-text— y el full-text usa BM25 y la sintaxis de consultas de Lucene. Todavía circula la información antigua de que “sparse es exclusivo de pods”, pero no es cierto: los tres funcionan en serverless.
• Modelos propios de embedding y reranking: ofrece su propio modelo de embeddings sparse, pinecone-sparse-english-v0, y como reranker utiliza bge-reranker-v2-m3. Los planes gratuito y Builder solo pueden usar ese reranker; a partir de Standard se accede al catálogo completo de modelos.
• Límites duros que conviene conocer (1): índices generales: 40 KB de metadatos por registro, top_k máximo de 10.000, tamaño de resultado de consulta máximo de 4 MB y los filtros de metadatos $in/$nin con un máximo de 10.000 valores por operador. Si tu canalización extrae un conjunto amplio de candidatos de un índice dense para rerankear, tienes mucho más margen del que sugieren la mayoría de los artículos.
• Límites duros que conviene conocer (2): solo para índices sparse: los índices sparse arrastran un conjunto de límites propio y bastante más estricto: máximo de 1.000 valores distintos de cero por vector sparse (el límite general del vector sparse es de 2.048), top_k máximo de 1.000, 10 upserts por segundo y 100 QPS en consultas. Muchos artículos comparativos copian estas cifras específicas de sparse como si fueran los límites globales de Pinecone: el techo de 1.000 en top_k solo aplica a índices sparse; el límite general es de 10.000. Lo que sí hay que planificar asumiendo la velocidad de sparse es la carga inicial masiva.
• El cambio de 2026: se ha creado el plan Builder de 20 $/mes con tarifa plana, que cubre el hueco que existía entre Starter y Standard. Está pensado exactamente para ese tramo de desarrolladores individuales y equipos pequeños a quienes el plan gratuito se les queda corto pero a quienes la facturación por consumo les da vértigo.

🦀 2) Qdrant: motor en Rust obsesionado con la eficiencia de memoria

• TurboQuant reduce la memoria a la mitad: introducido en la v1.18.0 (2026-05-11), TurboQuant es una técnica de cuantización desarrollada por Google Research. Aplica una rotación rápida de Hadamard a los vectores para redistribuir los valores de forma uniforme entre las coordenadas y después los comprime; según las mediciones del propio Qdrant, ahorra el doble de memoria que la cuantización escalar (SQ) manteniendo un recall y una velocidad similares. Permite llegar hasta una compresión de 8×. Teniendo en cuenta que buena parte del coste de una BD vectorial es RAM, esto no es simplemente una función más: impacta directamente en la factura.
• Más observabilidad para quien opera: en esa misma v1.18 se añadieron una interfaz web y una API de monitorización de memoria que desglosan el uso de disco, RAM y caché de página de una colección por componente: vectores, payload e índices. Es decir, ya se puede comprobar en lugar de adivinar por qué se está consumiendo tanta memoria. También llegaron una API de consulta del registro de auditoría e identificadores de traza de peticiones.
• Cambios de esquema sin parar el servicio: se pueden añadir y eliminar named vectors sin recrear la colección. Para un equipo que cambie de modelo de embeddings o experimente con multivector, esto ahorra íntegramente el coste de reindexar.
• La búsqueda híbrida es ciudadana de primera: desde la v1.7 hay vectores sparse nativos, así que puedes tener dense y sparse en una misma colección y resolverlo todo con una única consulta desde la Query API mediante RRF o fusión lineal ponderada.
• Viabilidad del proveedor: el 12 de marzo de 2026 cerró una Serie B de 50 M$, con lo que el acumulado asciende a 87,8 M$ (liderada por Advance Venture Partners, con Bosch Ventures como nuevo inversor). Es un dato que solo importa cuando valoras si el proveedor seguirá existiendo; no es un argumento sobre el producto.
• ¿Y a qué renuncias? Las contrapartidas de Qdrant: como sus fortalezas se concentran en la eficiencia de nodo único, Milvus tiene una arquitectura y un historial operativo más sólidos en cuanto empujas el escalado distribuido por encima de los 100 millones de vectores. Además, al no publicar tarifas unitarias en su página oficial, no puedes calcular un coste mensual exacto antes de comprometerte: hay que configurar una especificación en la consola o pedir presupuesto a ventas. En organizaciones con aprobaciones presupuestarias estrictas, esa fricción pesa más de lo que parece.
• Las versiones anteriores tampoco se quedaron cortas: la v1.17 (febrero de 2026) trajo consultas con Relevance Feedback y mejoras en la latencia de búsqueda, y la v1.16 incorporó multitenencia jerárquica (tenant promotion) y mejoras en la búsqueda vectorial con filtros basadas en ACORN. El último parche es la v1.18.3 (2026-07-17).

🕸️ 3) Weaviate: donde la búsqueda híbrida lleva más tiempo probada

• Una híbrida que se ajusta con un solo alpha: fusiona su módulo BM25 nativo con los vectores densos mediante un único parámetro alpha en la consulta. Poder inclinar la balanza hacia las palabras clave o hacia la búsqueda semántica cambiando un solo carácter es, en el trabajo real de iterar y afinar, una ventaja mayor de lo que parece. De los cinco productos, es el que lleva más tiempo operando búsqueda híbrida.
• La multitenencia es una función de primera clase: su fuerte es la combinación de aislamiento por tenant y búsqueda híbrida, lo que encaja de forma natural con el SaaS B2B que necesita separar los datos de cada cliente.
• Funciones prácticas llegadas en la v1.35: Object TTL (caducidad automática de objetos) permite depurar automáticamente los documentos antiguos, y se añadieron compresión zstd, índice flat + cuantización RQ en GA (estaba en preview en la 1.34), certificados OIDC configurables en tiempo de ejecución y operational modes (control por nodo del tipo de tareas que puede procesar).
• Embeddings directamente sobre imágenes de documentos: el módulo multi2multivec-weaviate de la v1.35 permite embeddings documentales multimodales, es decir, incrustar imágenes de documentos y buscarlas con consultas de texto. Si tu equipo trabaja con PDF escaneados, tablas o documentos con maquetación y quiere evitar una canalización de OCR, merece la pena mirarlo de cerca.
• La política de soporte es exigente: solo las tres últimas versiones menores (1.36 / 1.37 / 1.38) reciben parches de errores y de seguridad. La última es la v1.38.x (2026-06-05), precedida por la v1.37.x (2026-04-16), la v1.36.x (2026-02-24), la v1.35.x (2025-12-17) y la v1.34.x (2025-11-05). Aquí no funciona la costumbre operativa de dejar que una versión envejezca.

🐦 4) Milvus / Zilliz: escala distribuida y la irrupción de lo “lake-native”

• Milvus 3.0, con el concepto Lake-Native: anunciado el 27 de julio de 2026 y publicado el 29 de julio. Su núcleo es la indexación lake-native: ofrece “zero-copy external collections” que permiten consultar sin copiarlos a la base de datos vectorial los datos alojados en formatos de tabla abiertos dentro del object storage (Parquet / Lance / Iceberg / Vortex). En la práctica, significa saltarse la costumbre de replicar decenas de terabytes mediante ETL.
• Loon: nuevo motor de almacenamiento: un motor basado en manifiestos cuyo objetivo es reducir drásticamente la amplificación de lectura que se produce al hacer accesos puntuales de baja latencia contra el object storage. Su formato de almacenamiento por defecto es Vortex.
• Búsqueda y ranking dentro del propio motor: más allá de la simple búsqueda de vecinos más cercanos, el motor resuelve internamente ranking enriquecido, agregaciones, búsqueda sparse y búsqueda multivector. También llegaron SINDI para vectores learned-sparse, generación de MinHash en el servidor, campos vectoriales nullable, diccionarios personalizados para búsqueda de texto completo y soporte ampliado de índices compatibles con Faiss. Se incluyen además snapshots (vistas puntuales de una colección sin copia) e integración con Spark.
• Milvus 2.6 sigue plenamente vigente: con Woodpecker, su propio WAL cloud-native, eliminó la dependencia de Kafka y Pulsar. Al ser un diseño zero-disk, persiste todos los registros en object storage como S3, GCS o MinIO, y desde la 2.6 el WAL es opcional. Se creó el Streaming Node, que colabora con el Query Node y el Data Node, y se reforzaron el almacenamiento por niveles, la cuantización RaBitQ, la búsqueda de texto completo y la multitenencia. El fabricante afirma un 72 % menos de memoria (manteniendo el recall) y un rendimiento 4 veces superior al de Elasticsearch, cifras que conviene leer teniendo en cuenta que son mediciones del propio Milvus (Zilliz).
• Novedades recientes del Zilliz Cloud gestionado: desde el 1 de enero de 2026 unificó el precio del almacenamiento en 0,04 $/GB al mes en los tres proveedores: AWS, Azure y GCP. Con la llegada de la transferencia de datos entre regiones y entre nubes, los costes de transferencia se repercuten al coste del proveedor, sin margen añadido. Milvus 2.6.x alcanzó la GA en Zilliz Cloud el 20 de enero de 2026, y Zilliz sostiene —según sus propias mediciones— que su almacenamiento multinivel logra en producción una tasa de aciertos de caché superior al 90 % y hasta un 87 % de ahorro en costes de almacenamiento.
• Las herramientas de operación también se están renovando: con la llegada de Attu 3.0 Beta (julio de 2026) se incorporaron la gestión multiclúster, agentes de IA y una reescritura completa de la consola.

🐘 5) pgvector: la opción más contundente, la de “no adoptar una base de datos nueva”

• Empieza por comprobar la versión: la última es la 0.8.6 (2026-07-29). “pgvector 0.9” no existe. Varios blogs técnicos lo escriben mal, así que conviene verificarlo antes de copiar y pegar el dato en la documentación interna.
• 🔴 CVE-2026-3172: lo que hay que revisar ahora mismo: durante la construcción paralela de índices HNSW se produce un desbordamiento de búfer causado por un wraparound de enteros. Las versiones afectadas son de la 0.6.0 a la 0.8.1, y la corrección está en la 0.8.2. Un usuario de la base de datos con capacidad para crear índices HNSW con workers paralelos o ejecutar REINDEX podría filtrar datos sensibles de otras relaciones o provocar la caída del servidor. Si no puedes parchear de inmediato, como mitigación temporal configura max_parallel_maintenance_workers = 0 para desactivar la construcción paralela de HNSW.
• Las releases de 2026 se suceden a buen ritmo: la 0.8.3 (2026-06-17) corrigió una posible corrupción del índice durante el vacuum de HNSW y una degradación del rendimiento en el cálculo de distancias en PostgreSQL 18; la 0.8.4 (2026-06-30) arregló los mensajes de error del vacuum de HNSW, problemas de inserción durante el mantenimiento y una sobreasignación de memoria en la construcción de IVFFlat. La 0.8.5 (2026-07-08) redujo los requisitos de memoria para construir índices IVFFlat en conjuntos de datos pequeños, y la 0.8.6 solucionó un desbordamiento de búfer en la construcción de IVFFlat en sistemas de 32 bits, el límite de valores distintos de cero al convertir de array a sparsevec y la memoria de los escaneos IVFFlat en nested loop joins. Que las correcciones se encadenen así también es señal de que hay mucho uso real en producción.
• Dos índices: HNSW e IVFFlat: HNSW ofrece un excelente equilibrio entre velocidad y recall, pero se construye más despacio y consume más memoria. IVFFlat se construye rápido y es más ligero. Si subes maintenance_work_mem en una construcción paralela de HNSW, tendrás que aumentar el tamaño de memoria compartida al menos en la misma proporción para no encontrarte con errores. El soporte de PostgreSQL 18 llegó con la 0.8.1 (2025-09-04).
• Su mayor debilidad es la híbrida: no incorpora búsqueda híbrida. Hay que calcular por separado la búsqueda de texto completo con tsvector y la distancia vectorial, y después fusionarlas manualmente en el código de la aplicación (por ejemplo con RRF). Es el punto que más trabajo manual exige de los cinco, y ese único apartado es el motivo más habitual para dar el salto a una base de datos vectorial dedicada.
• Si quieres exprimir aún más el rendimiento: pgvectorscale 0.9.0, de Timescale, es una extensión aparte que se monta sobre pgvector; añadió soporte para PG18, eliminó el soporte de PG13 y admite construcción concurrente de índices. Si te interesan las alternativas dentro del propio Postgres, el artículo Comparativa de bases de datos: PostgreSQL, MySQL y MongoDB te ayudará a ver el cuadro completo de tu stack.

3. Duelo de benchmarks de rendimiento: siendo honestos, “mídelo tú mismo”

Si esperabas una tabla espectacular de QPS en esta sección, te lo adelanto ya: a agosto de 2026 no existe ningún benchmark público, con verificación cruzada y fiable, que compare estos cinco productos en igualdad de condiciones. Por eso no vamos a construir esa tabla. Construirla sería mentir.

Basta con ver hasta qué punto se contradicen las cifras que circulan. Una misma fuente afirma en el mismo párrafo que Qdrant alcanza 41,47 QPS con 50 millones de vectores mientras atribuye a pgvectorscale 471 QPS. Son diez veces de diferencia, y no se especifica ni el hardware ni los parámetros del índice. Con la latencia p99 pasa igual: conviven una fuente que dice “con 10 millones de vectores, Qdrant unos 12 ms, Weaviate unos 16 ms y Milvus unos 18 ms” y otra que sostiene “Qdrant por debajo de 8 ms”. Frases tan impactantes como “Pinecone: mil millones de vectores, 50 ms p95 y 10.000 QPS frente a Qdrant: 20 ms p95 y 15.000 QPS” acaban, si sigues la fuente, convergiendo en un único blog de SEO, y las condiciones no aparecen por ninguna parte.

[Valoración cualitativa según las fortalezas arquitectónicas — no son cifras, son tendencias]
Qdrant   : ⭐⭐⭐⭐⭐ Latencia en nodo único (HNSW en Rust optimizado con SIMD)
Milvus   : ⭐⭐⭐⭐⭐ Rendimiento a muy gran escala (arquitectura distribuida, 100 M+ vectores)
Weaviate : ⭐⭐⭐⭐☆ Optimizado para cargas híbridas (caída de QPS con filtros pesados)
Pinecone : ⭐⭐⭐⭐☆ Rendimiento estable sin carga operativa (poco margen de ajuste)
pgvector : ⭐⭐⭐☆☆ Hasta el millón de vectores, a la altura de una BD dedicada en la práctica

Por eso es más preciso hablar de la tendencia de cada arquitectura en lugar de cifras. De Qdrant se sabe que destaca en latencia de nodo único gracias a su HNSW en Rust con optimizaciones SIMD. Milvus, al ser una arquitectura distribuida, saca ventaja en rendimiento por encima de los 100 millones de vectores. Weaviate está optimizado para cargas híbridas, aunque se reporta una tendencia a perder QPS cuando los filtros de metadatos se vuelven pesados. Sobre pgvector, la valoración generalizada es que con índices HNSW compite en la práctica de tú a tú con las bases de datos vectoriales dedicadas hasta el orden del millón de vectores.

Los benchmarks del propio fabricante tienen valor de referencia siempre que se cite la fuente. El 72 % de ahorro de memoria y el rendimiento 4 veces superior a Elasticsearch de Milvus 2.6 son mediciones de Zilliz, igual que la tasa de aciertos de caché superior al 90 % y el ahorro de hasta el 87 % en almacenamiento del almacenamiento multinivel de Zilliz Cloud. Y la memoria a la mitad frente a SQ y la compresión de hasta 8× de TurboQuant son mediciones del propio Qdrant. Conviene leer las tres cifras más o menos como el “consumo homologado” que anuncia un fabricante de coches. Por cierto: Milvus 3.0 lleva una semana en el mercado, así que todavía no existen benchmarks independientes. Si ahora mismo encuentras un artículo que presenta cifras de rendimiento de la 3.0, tienes motivos de sobra para desconfiar de su fuente.

En conclusión, la respuesta práctica a este apartado es una sola: ejecuta tú mismo ANN-Benchmarks o VectorDBBench con tus embeddings, tus dimensiones, tus condiciones de filtrado y tu hardware. 1536 dimensiones y 384 dimensiones son juegos completamente distintos, y no es raro que el orden se invierta en cuanto entra en escena un filtro de metadatos. Una arquitectura elegida a partir del benchmark de otro suele convertirse en arrepentimiento durante el primer mes en producción.

4. Comparativa completa de planes y precios

El precio es el terreno donde más malentendidos hay en esta comparativa de bases de datos vectoriales. En concreto, las tarifas de Read/Write Unit de Pinecone que se citan por ahí difieren de la página oficial en aproximadamente el doble. Todo lo que sigue procede de las páginas de precios oficiales.

[Barrera de entrada al pago — por coste mínimo mensual]
pgvector          : 0 $        (código abierto, solo pagas el hosting de Postgres)
Pinecone Builder  : 20 $/mes    (tarifa plana, 10 GB de almacenamiento incluidos)
Weaviate Flex     : desde 45 $/mes (PAYG, subió de 25 $ tras el rediseño de 10/2025)
Pinecone Standard : 50 $/mes    (gasto mínimo, no es tarifa plana)
Weaviate Premium  : desde 400 $/mes (contrato prepagado)
Pinecone Enterprise: 500 $/mes  (gasto mínimo, SLA del 99,95 %)
Qdrant / Zilliz   : por consumo — tarifas unitarias no publicadas, hay que consultar

💰 Tarifas oficiales de Pinecone

Muchos artículos comparativos indican que el Read Unit de Pinecone cuesta 8,25 $ por millón y el Write Unit 2,00 $ por millón. Los valores oficiales para Standard son 16–18 $ por millón de RU y 4–4,50 $ por millón de WU. Si has hecho tu modelo de presupuesto con esas cifras equivocadas, la factura real será el doble de lo previsto. Como no está confirmado oficialmente cuándo se produjo la subida, es más prudente no afirmar que “ha subido” y quedarse con que el precio oficial actual es este.

💰 Tarifas oficiales de Weaviate

Lo que hay que subrayar sin falta en Weaviate es que la unidad de facturación es “un millón de dimensiones”. No se calcula por número de vectores, sino por número de vectores × número de dimensiones, de modo que usar un modelo de embeddings de 1536 dimensiones cuadruplica el coste frente a uno de 384 dimensiones con el mismo número de documentos. Es una estructura en la que elegir el modelo de embeddings equivale a decidir tu coste de infraestructura. Además, en octubre de 2025 se rediseñaron por completo las tarifas: desaparecieron los niveles Serverless/Enterprise, se sustituyeron por el esquema Flex/Premium y el precio de entrada subió de 25 $ a 45 $. Por cierto, el nivel “Plus de 280 $” que mencionan algunos artículos no existe en la página oficial. El Sandbox gratuito ofrece 100.000 objetos / 1 GB de memoria / 10 GB de disco / 1 colección / hasta 3 tenants, y Dedicated cubre unas 40 regiones de las principales nubes, mientras que los niveles inferiores tienen las regiones limitadas.

💰 Qdrant, Zilliz y pgvector

Hablemos ahora de los costes ocultos. Primero: ninguno de los cinco publica una lista de precios oficial en euros (ni, para quien investigue el mercado coreano, en wones surcoreanos). Todos facturan en dólares estadounidenses, así que las fluctuaciones del tipo de cambio se trasladan directamente al presupuesto, y cualquier “X € al mes” que hayas visto por ahí es una conversión que alguien ha hecho por su cuenta, no un precio oficial. Segundo: “gasto mínimo” y “tarifa plana” son cosas completamente distintas. Los 50 $ de Pinecone Standard no son una cuota fija sino un gasto mínimo, de modo que si crece el tráfico, la facturación por RU/WU se acumula por encima de esa cifra. Los 20 $ de Builder, en cambio, sí son tarifa plana y por eso resultan fáciles de prever. Tercero: el “gratis” del autoalojamiento es una cifra a la que le falta el coste de personal. Si operas Qdrant o Milvus por tu cuenta, la licencia cuesta cero, pero las copias de seguridad, la monitorización, las actualizaciones y la respuesta a incidencias se comen el tiempo del equipo. Sin alguien dedicado a infraestructura, un servicio gestionado de 50 $ sale más barato que el autoalojamiento en muchos casos. Y si te interesa la estructura de costes de la propia cuenta cloud, leer también Comparativa de proveedores cloud: AWS, GCP y Azure hará que tu cálculo del coste total de propiedad (TCO) sea mucho más preciso.

5. Guía de recomendación final por perfil de usuario

🎯 1) Equipos que ya operan PostgreSQL y manejan menos de 10 millones de vectores

• Mejor opción: pgvector
• Por qué: adoptar una base de datos nueva significa crear desde cero una canalización de sincronización y un sistema más que operar. Solo con poder confirmar en la misma transacción el registro original y su embedding desaparece la mitad de los errores de consistencia. Con índices HNSW, la valoración generalizada es que a esta escala compite de tú a tú con una BD dedicada en la práctica. Eso sí, antes de empezar comprueba sin falta que la versión sea 0.8.2 o superior.

🎯 2) Startups en fase inicial o desarrolladores en solitario sin ingeniero de infraestructura

• Mejor opción: Pinecone Builder o Qdrant Free
• Por qué: Pinecone Builder ofrece por 20 $/mes de tarifa plana 10 GB de almacenamiento junto con 5 M de WU y 2 M de RU, así que la factura no da sustos. Si tu presupuesto es cero, el plan gratuito permanente de Qdrant (0,5 vCPU / 1 GB RAM / 4 GB de disco) se puede usar indefinidamente sin límite temporal, algo ideal para la fase de prototipo.

🎯 3) SaaS B2B que exige aislamiento de datos por cliente

• Mejor opción: Weaviate
• Por qué: la multitenencia por sí sola no es exclusiva de Weaviate: Qdrant incorporó multitenencia jerárquica (tenant promotion) en la v1.16 y Milvus 2.6 reforzó la suya. La razón real para elegir Weaviate es que el aislamiento por tenant y la búsqueda híbrida BM25 nativa vienen combinados en un mismo producto. La búsqueda documental B2B está llena de consultas que exigen coincidencia exacta (números de contrato, SKU), lo que convierte la híbrida por tenant en algo prácticamente obligatorio, y además Object TTL automatiza los plazos contractuales de destrucción de datos. Si no necesitas las tres cosas a la vez, sino solo el aislamiento, Qdrant es una segunda opción perfectamente válida. Ahora bien, como en Weaviate la facturación se basa en el número de dimensiones, si vas a usar embeddings de alta dimensión conviene hacer antes una simulación de costes.

🎯 4) Grandes empresas que ya operan un data lake (Iceberg/Parquet)

• Mejor opción: Milvus 3.0
• Por qué: la indexación lake-native permite consultar tablas Parquet, Lance, Iceberg y Vortex sin copiarlas. Desaparecen de golpe tanto el ETL que replicaba decenas de terabytes hacia la base de datos vectorial como el coste de ese doble almacenamiento. Eso sí, como lleva una semana desde el anuncio, valídalo primero en staging y, si la estabilidad es tu máxima prioridad, considera en paralelo la rama 2.6 ya en GA.

🎯 5) Equipos sensibles al coste que tampoco quieren renunciar a la calidad de un RAG en producción

• Mejor opción: Qdrant
• Por qué: lo decisivo es que TurboQuant reduce la memoria a la mitad frente a la cuantización escalar. Como buena parte del coste de una BD vectorial es RAM, ese ahorro se traduce directamente en la factura de infraestructura. Y con sparse nativo más fusión RRF, la búsqueda híbrida se resuelve en unas pocas líneas de código.

🎯 6) Equipos de escala intermedia: entre 10 y 100 millones de vectores, sin data lake y tampoco sobre Postgres

• Mejor opción: Qdrant si tienes a alguien que lo opere; Pinecone Standard si no lo tienes
• Por qué: este es en realidad el despliegue de RAG en producción más habitual, y se cuela justo por el hueco que dejan los umbrales anteriores. pgvector empieza a incomodar en torno a los diez millones de vectores, cuando el tiempo de construcción del índice y la memoria se disparan; y la indexación lake-native de Milvus 3.0 no aporta nada sin un data lake, dejándote solo con la complejidad operativa de una arquitectura distribuida. Por eso la pregunta decisiva no es la escala, sino si tienes a una persona para operar esto. Si alguien se ocupa de copias de seguridad, monitorización y actualizaciones, Qdrant ofrece la mejor relación coste-calidad gracias a su eficiencia de memoria (TurboQuant) y a la híbrida nativa. Si no hay nadie, Pinecone Standard elimina por completo esa carga de personal. Eso sí, presupuesta teniendo en cuenta que Standard es un gasto mínimo de 50 $/mes sobre el que se acumulan RU/WU, no una tarifa plana.

🎯 7) Organizaciones de sectores regulados (finanzas, sanidad) donde el SLA y los requisitos de auditoría van primero

• Mejor opción: Pinecone Enterprise, Zilliz Cloud Business Critical o Qdrant Private Cloud
• Por qué: ordenarlos solo por la cifra del SLA te llevará a equivocarte. En los niveles más altos tenemos Pinecone Enterprise con 99,95 %, Qdrant Standard multi-AZ con 99,95 % y Zilliz Cloud Business Critical con 99,99 % (multirréplica): la disponibilidad está prácticamente igualada y es Zilliz quien publica la cifra más alta. Los verdaderos diferenciales están en lo contractual y lo auditable. Pinecone Enterprise reúne HIPAA, registro de auditoría y BYOC, y este último se despliega en la cuenta cloud del cliente en modo zero-access. Business Critical de Zilliz Cloud es el plan que su documentación oficial dirige explícitamente a sanidad, finanzas y sistemas de misión crítica, e incluye también BYOC (99,95 %), así que debe estar en tu lista si tienes requisitos regulatorios. Y si los datos no pueden salir físicamente de tu perímetro, la Private Cloud de Qdrant (despliegue dedicado totalmente aislado) o el autoalojamiento son las respuestas realistas.

🎯 8) Equipos que necesitan montar rápido una búsqueda documental o base de conocimiento interna

• Mejor opción: Weaviate o Pinecone
• Por qué: la documentación interna está llena de palabras clave que deben coincidir de forma exacta, como nombres de producto, números de empleado o referencias normativas, así que la búsqueda puramente vectorial fracasa. Optar por una solución que traiga la híbrida de serie —la fusión con alpha de Weaviate o el índice full-text de Pinecone (BM25 + sintaxis Lucene)— reduce enormemente el tiempo de desarrollo. Y si aún estás decidiendo qué LLM conectar, el artículo Comparativa de modelos de IA: ChatGPT, Claude y Gemini te será de ayuda.

6. Consejos prácticos y errores frecuentes

✅ Consejo 1) Revisa hoy mismo la versión de pgvector

Ejecuta SELECT extversion FROM pg_extension WHERE extname = 'vector';. Si es anterior a la 0.8.2, estás expuesto a la CVE-2026-3172. Es una vulnerabilidad que permite a un usuario con capacidad de crear índices HNSW con workers paralelos filtrar datos de otras relaciones o tumbar el servidor. Si usas un Postgres gestionado, comprueba cuándo actualizó tu proveedor a la 0.8.2 o superior, y si no puedes actualizar de inmediato, la defensa temporal es bloquear la construcción paralela de HNSW con max_parallel_maintenance_workers = 0. En la medida de lo posible, lo mejor es subir hasta la última versión, la 0.8.6, porque la 0.8.3 corrigió además una posible corrupción del índice durante el vacuum de HNSW.

✅ Consejo 2) La búsqueda híbrida ya no es opcional

En el RAG en producción de 2026, la búsqueda híbrida (BM25 + vectorial) se ha convertido en el estándar. En corpus intensivos en conocimiento, la búsqueda puramente vectorial se deja fuera consultas de coincidencia exacta como nombres propios, códigos o cifras. El problema es que es justo aquí donde más se abre la brecha de madurez entre productos.

Para hacer híbrida con pgvector tienes que escribir tú mismo la lógica de fusión, por ejemplo RRF. Se puede construir, sí, pero ese código se convierte en un activo que exige ajuste y mantenimiento continuos. “¿Es imprescindible la híbrida?” es la pregunta más práctica para decidir si te quedas en pgvector o lo abandonas.

✅ Consejo 3) Vuelve a mirar el número de dimensiones desde la óptica del coste

Weaviate factura por millón de dimensiones. Un millón de documentos con embeddings de 1536 dimensiones son 1.536 millones de dimensiones, mientras que con un modelo de 384 dimensiones se quedan en 384 millones. Si la calidad de la búsqueda lo aguanta, reducir dimensiones o pasar a un modelo de menor dimensionalidad supone un ahorro inmediato de 4×. Y aunque no uses Weaviate, el número de dimensiones influye en el coste de cualquier base de datos vectorial a través del consumo de memoria. Si además le sumas cuantización —TurboQuant en Qdrant, la cuantización RQ en Weaviate o RaBitQ en Milvus—, el margen de ahorro crece todavía más.

✅ Consejo 4) Incorpora los límites duros de Pinecone en la fase de diseño

Hay restricciones que duelen mucho si te las encuentras cuando ya estás en producción. 40 KB de metadatos por registro: aquí choca de frente cualquier diseño que meta el texto completo del documento en los metadatos. top_k de 10.000 como máximo en índices generales y 4 MB de tamaño máximo de resultado: si tu canalización pretende extraer un buen número de candidatos para pasárselos al reranker, tienes margen de sobra, y en la práctica lo normal es chocar antes con el tope de 4 MB del resultado. El techo de 1.000 solo te afecta si rerankeas sobre un índice sparse. Confundir ese 1.000 específico de sparse con un límite global de Pinecone y recortar sin necesidad el conjunto de candidatos dense es un error de diseño muy frecuente. $in/$nin con un máximo de 10.000 valores por operador: el patrón de pasar los permisos de usuario como una lista de IDs revienta cuando la organización crece. Y los índices sparse tienen un límite de 10 upserts/s y 100 QPS en consultas, así que la carga inicial masiva hay que planificarla asumiendo esa velocidad.

✅ Consejo 5) Con Weaviate no puedes dejar envejecer la versión

Weaviate solo da parches de errores y de seguridad a las tres últimas versiones menores (1.36/1.37/1.38). Como el ciclo de releases es de aproximadamente dos meses, con medio año de dejadez ya te quedas fuera del rango soportado. Lo mejor es fijar directamente en el calendario del equipo una actualización trimestral.

✅ Consejo 6) Decide la adopción de Milvus 3.0 según si tienes o no un data lake

La indexación lake-native de la 3.0 solo cambia las reglas del juego para organizaciones que ya tienen datos en formatos de tabla abiertos dentro de su object storage. Si tus datos viven de entrada en Postgres o en la base de datos de la aplicación, el valor central de la 3.0 no llega a manifestarse y solo cargas con la complejidad operativa de una arquitectura distribuida. Además, al llevar una semana desde el anuncio, todavía no hay benchmarks independientes. Valídalo en staging con tus propios datos antes de dar el paso y, si la estabilidad es lo primero, la rama 2.6.x, que alcanzó la GA en Zilliz Cloud el 20 de enero de 2026, sigue siendo una elección perfectamente razonable.

✅ Consejo 7) Calcula el coste real del “ya migraremos más adelante”

La conclusión de este artículo es “empieza por pgvector”, y ese consejo solo se sostiene si sabes lo que cuesta el paso de migrar. Empecemos por la buena noticia: normalmente no hace falta volver a generar los embeddings. Los vectores son arrays de números reales que puedes exportar e importar tal cual, así que no vuelves a pagar la API de embeddings. Solo hay reembedding completo si además cambias de modelo.

Lo que de verdad cuesta dinero y tiempo son las otras cuatro cosas. Primera, el tiempo de reconstrucción del índice: HNSW se construye despacio y consume mucha memoria, así que a cierta escala el calendario no lo marca el traslado, sino cuánto tarda el sistema nuevo en terminar de construir los índices. Segunda, el mapeo del esquema de IDs y metadatos: cada producto tiene restricciones distintas en el tipo de ID, en el modelo de metadatos/payload y en la sintaxis de filtrado, de modo que acabas reescribiendo las consultas con filtros. Tercera, el periodo de escritura dual (dual-write): para hacer un corte sin caída hay que escribir un tiempo en ambos sistemas y comparar resultados, y durante esa ventana pagas los dos. Cuarta, la validación de regresión en la calidad de recuperación: al cambiar de motor, la misma consulta se ordena de otra forma, así que hay que volver a pasar la evaluación con tu conjunto de referencia.

Esto es exactamente lo que significa el “bloqueo de proveedor” que la tabla del apartado 1 señala como mayor pega de Pinecone. Pinecone no tiene ruta de autoalojamiento (BYOC es un contrato aparte), así que en el momento en que decides irte tienes que levantar una infraestructura sustitutiva desde cero y, encima, pagar los cuatro costes anteriores. Qdrant, Milvus y pgvector te dejan al menos la salida de “seguimos ejecutando el mismo motor en nuestros propios servidores”. Escribir y ejecutar una sola vez un script de exportación, ya en el momento de la adopción, te dice de antemano si ese coste es asumible.

❌ Error frecuente 1) Decidir la arquitectura con el benchmark de otro

Como hemos visto, las cifras públicas se desvían entre sí por factores de diez. Si cambian las dimensiones, las condiciones de filtrado o el hardware, el propio ranking se da la vuelta. Reduce los candidatos a dos y dedica media jornada a medir con tus propios datos: sale infinitamente más barato que perder medio año por una elección equivocada.

❌ Error frecuente 2) Contabilizar el autoalojamiento como “gratis”

La licencia Apache 2.0 significa que el coste de licencia es cero, no que el coste operativo lo sea. Copias de seguridad, pruebas de recuperación, monitorización, actualizaciones de versión y respuesta a incidencias son todo tiempo del equipo. En organizaciones sin responsable de infraestructura, la tarifa de un servicio gestionado suele salir más barata.

❌ Error frecuente 3) Meter en el presupuesto precios citados sin verificarlos

Las tarifas de RU/WU de Pinecone que más se citan difieren del precio oficial en aproximadamente el doble, el precio de entrada de Weaviate pasó de 25 $ a 45 $ en octubre de 2025 y la “0.9” de pgvector sencillamente no existe. La costumbre de abrir la página de precios oficial antes de meter una cifra en un documento de presupuesto te evitará más de un mal rato en una reunión.

7. Preguntas frecuentes (FAQ)

P. ¿Cuál es la primera pregunta que hay que plantearse en una comparativa de bases de datos vectoriales?

“¿Ya estamos usando PostgreSQL?”. Si la respuesta es sí y manejas menos de diez millones de vectores, pgvector es la opción por defecto, y adoptar una base de datos vectorial dedicada equivale a fabricarte un coste nuevo en forma de sistema que operar y canalización de sincronización. La siguiente pregunta es “¿vamos a pagar por un servicio gestionado o lo operamos nosotros?”, y la última, “¿es imprescindible la búsqueda híbrida?”. Con esas tres preguntas los cinco candidatos se reducen a dos.

P. ¿Es viable poner un RAG en producción con pgvector?

Depende de la escala y de los requisitos. Con índices HNSW, la valoración generalizada es que al orden del millón de vectores compite de tú a tú con una base de datos vectorial dedicada, y la ventaja de gestionarlo en la misma transacción que los datos originales es enorme. Ahora bien, no incluye búsqueda híbrida, así que tendrás que fusionar tsvector y distancia vectorial en el código de la aplicación. El criterio de decisión es si puedes asumir esa carga de implementación y mantenimiento.

P. ¿La última versión de pgvector es la 0.9?

No. La 0.9 no existe. A 2 de agosto de 2026 la última es la 0.8.6 (2026-07-29). Varios blogs técnicos la citan mal como 0.9, así que ten cuidado. Y como todo lo anterior a la 0.8.2 es vulnerable a la CVE-2026-3172, comprobar la versión no es una cuestión de rigor informativo, sino de seguridad.

P. ¿Dónde conviene más empezar gratis?

Depende del uso. Qdrant Free es gratis para siempre, sin límite temporal, con 0,5 vCPU / 1 GB RAM / 4 GB de disco, e incluye inferencia cloud gratuita para algunos modelos, lo que lo hace ideal para prototipar. Weaviate Sandbox ofrece 100.000 objetos / 1 GB de memoria / 10 GB de disco / 1 colección / hasta 3 tenants, perfecto para experimentar con búsqueda híbrida. Pinecone Starter incluye 2 GB de almacenamiento, 2 M de WU y 1 M de RU al mes, y hasta 5 M de tokens de embedding. Zilliz Cloud también ofrece un nivel con el que empezar gratis, pero sus límites no figuran como cifras en la página oficial de precios, así que compruébalos en la consola antes de comparar. Y si puedes gestionar la infraestructura por tu cuenta, pgvector y las versiones autoalojadas de Qdrant y Milvus son totalmente gratuitas.

P. Se dice mucho que Pinecone es caro. ¿Cuánto cuesta en realidad?

Según las cifras oficiales, Standard cuesta 16–18 $ por millón de RU de lectura y 4–4,50 $ por millón de WU de escritura, con el almacenamiento a 0,33 $/GB al mes y un gasto mínimo mensual de 50 $. Enterprise sube a 24–27 $ por RU y 6–6,75 $ por WU, con un mínimo de 500 $ al mes. Las cifras que circulan por internet, del tipo “RU a 8,25 $”, no coinciden con las oficiales, así que no las uses para calcular presupuestos. Si tu tráfico no es grande, Builder, con su tarifa plana de 20 $/mes, es lo más seguro en términos de previsibilidad de costes.

P. ¿Debería migrar ya mismo a Milvus 3.0?

Si ya operas un data lake, merece mucho la pena estudiarlo. Sus dos claves son la indexación lake-native, que permite consultar tablas Parquet, Lance, Iceberg y Vortex sin copiarlas, y Loon, el nuevo motor de almacenamiento que reduce la amplificación de lectura. Ahora bien, se publicó el 29 de julio de 2026, así que lleva apenas una semana y no existen benchmarks independientes. Valídalo en staging antes de migrar y, si la estabilidad es prioritaria, la 2.6.x que alcanzó la GA en Zilliz Cloud en enero de 2026 sigue siendo una muy buena elección.

P. ¿Por qué la factura de Weaviate sale más alta de lo previsto?

Porque la unidad de facturación no es el número de vectores, sino “un millón de dimensiones”. Como se calcula multiplicando vectores por dimensiones, usar un modelo de 1536 dimensiones cuadruplica el coste frente a uno de 384 con el mismo número de documentos. A eso se suma que el rediseño de tarifas de octubre de 2025 subió el precio de entrada de 25 $ a 45 $. Cambiar a un modelo de embeddings de menor dimensionalidad o aplicar cuantización es la vía de ahorro más directa.

P. ¿Se puede pagar en euros?

Ninguno de los cinco tiene una lista de precios oficial en euros (ni en wones surcoreanos, por si estás evaluando el mercado coreano). Todos facturan en dólares estadounidenses, de modo que las fluctuaciones del tipo de cambio se reflejan íntegramente en el coste. Las expresiones tipo “X € al mes” que verás en otros artículos comparativos son conversiones arbitrarias, no precios oficiales, así que lo más seguro es redactar los documentos de aprobación de presupuesto en dólares y reservar aparte un margen para la variación del cambio.

P. ¿Dónde consulto las tarifas exactas de Qdrant Cloud?

Qdrant no publica cifras concretas de precios en su página oficial. Solo hace pública la estructura: los conceptos facturables son cómputo (vCPU), memoria (GB), almacenamiento (GB), almacenamiento de copias de seguridad y tokens de inferencia de pago, y el cálculo es por hora. Las cifras que circulan por internet, como “0,078 $/GB-hora” o “desde 25 $ al mes”, no están confirmadas oficialmente, así que no te las creas sin más: si necesitas un presupuesto real, lo preciso es configurar en la consola las especificaciones que quieres o hablar directamente con su equipo comercial.

8. Conclusión: la verdadera conclusión de la comparativa de bases de datos vectoriales de 2026

El mercado de bases de datos vectoriales de agosto de 2026 ha dejado atrás la pregunta de “quién es más rápido”. Milvus resuelve un problema con lo lake-native, consultando allí donde ya están los datos; Qdrant, con una cuantización que ofrece el mismo recall con la mitad de memoria; Weaviate, con híbrida y multitenencia; Pinecone, con un servicio totalmente gestionado que reduce a cero la carga operativa; y pgvector, con la vía de no introducir ninguna infraestructura nueva. No se sustituyen entre sí: la respuesta cambia según la situación de cada organización.

Por eso, la conclusión práctica de esta comparativa de bases de datos vectoriales es la siguiente: primero comprueba si puedes empezar con pgvector y, solo cuando confirmes que la búsqueda híbrida o la escala te lo impiden, pasa a una base de datos vectorial dedicada. Buena parte de los equipos que adoptan desde el principio una BD dedicada y vistosa acaban gastando su tiempo en carga operativa y errores de sincronización. Y al revés: los equipos que necesitan híbrida sí o sí pero se empeñan en quedarse con pgvector pagan el precio en calidad de recuperación. El criterio no debe ser la preferencia personal, sino los requisitos.

Por último, hay una cosa que deberías hacer hoy mismo. Si usas pgvector, comprueba tu versión. Las versiones de la 0.6.0 a la 0.8.1 están afectadas por la CVE-2026-3172, corregida en la 0.8.2. Si de este artículo solo te llevas una cosa, que no sea una tabla de benchmarks, sino esta línea.

[Resumen: la recomendación final según tu situación]

Ya usas PostgreSQL + menos de 10 millones de vectores
  → pgvector (obligatorio 0.8.2 o superior / última: 0.8.6)

Sin personal de infraestructura + la previsibilidad de costes es lo primero
  → Pinecone Builder (20 $/mes fijos, 10 GB, 5 M WU y 2 M RU)

Prototipo con presupuesto cero
  → Qdrant Free (gratis para siempre, 0,5 vCPU / 1 GB RAM / 4 GB de disco)

SaaS B2B que necesita aislar los datos por cliente
  → Weaviate (multitenencia + híbrida BM25 con alpha / ojo a la facturación por dimensiones)

Gran empresa con data lake (Iceberg, Parquet)
  → Milvus 3.0 (lake-native, consulta sin copia / tras validar en staging)

Reducir el coste de memoria manteniendo la calidad del RAG en producción
  → Qdrant (TurboQuant: la mitad de memoria que SQ, compresión de hasta 8×)

Entre 10 y 100 millones de vectores, sin data lake y sin Postgres
  → Qdrant si tienes quien lo opere; si no, Pinecone Standard (mín. 50 $/mes)

HIPAA, registro de auditoría y residencia del dato como condiciones contractuales
  → Pinecone Enterprise (mínimo 500 $/mes) / Zilliz Business Critical (99,99 %)
     / Qdrant Private Cloud — en SLA los tres superan el 99,95 %

⚠️ Común a todos: ninguno de los cinco publica precios oficiales en euros (facturan en USD),
   y los benchmarks públicos usan condiciones dispares: mide siempre por tu cuenta

Coge solo dos candidatos y mídelos tú mismo con tus datos, tus dimensiones y tus condiciones de filtrado. Esa media jornada te dará una respuesta más precisa que este artículo entero. 🚀