Situación de las bases de datos vectoriales, segundo trimestre de 2026

El impulso de Qdrant en 2026 pone de manifiesto que el mercado de las bases de datos vectoriales se está fragmentando, en lugar de desaparecer.

En 2025, el director ejecutivo de Elastic, Ashutosh Kulkarni, declaró que«las bases de datos vectoriales son una funcionalidad. Nunca van a ser un negocio en sí mismas».El 12 de marzo de 2026, Qdrant recaudó 50 millones de dólares en una ronda de financiación de serie B, superó los 250 millones de descargas y lanzó la versión 1.17. En junio de 2026, el proyecto alcanzó las 32 400 estrellas en GitHub, frente a las 27 000 que tenía en diciembre de 2025. Research and Markets prevé que el mercado de las bases de datos vectoriales crecerá de 3 730 millones de dólares en 2026 a 10 600 millones de dólares en 2032, con una tasa de crecimiento anual compuesto (CAGR) del 23,5 %. Una categoría en declive no genera esas cifras.

Resumen del crecimiento trimestral

Ashutosh describió una presión real sobre los recursos, pero solo en una parte del mercado. PostgreSQL, con pgvector, ahora absorbe cargas de trabajo de menos de 50 millones de vectores y reduce el coste total de propiedad (TCO) entre un 40 % y un 60 %. Los índices Hierarchical Navigable Small World (HNSW) e Inverted File Flat (IVFFlat) permiten la búsqueda por «vecino más cercano aproximado» (ANN), mientras que PostgreSQL mantiene el cumplimiento de ACID, algo que las bases de datos vectoriales nativas no ofrecen. La combinación de la búsqueda por palabras clave y la similitud vectorial dentro de la propia base de datos en un único sistema elimina la necesidad de un almacén vectorial independiente. Ese es el segmento de mercado que el argumento de Ashutosh capta con precisión.

A partir de los 50 millones de vectores, las diferencias de rendimiento se hacen evidentes. pgvector almacena las representaciones directamente en tablas de PostgreSQL. Un conjunto de datos con 1 millón de vectores (de 1.536 dimensiones) ocupa aproximadamente 6 GB solo en vectores, a lo que hay que añadir entre 3 y 4 GB más correspondientes a la indexación HNSW con la configuración predeterminada. El tiempo de creación del índice aumenta con cada nueva carga de trabajo, y la latencia pasa de 50 ms a 800 ms una vez superada la barrera de los 10 millones de representaciones en una instancia con 1 TB de RAM.

Las cargas de trabajo a escala de miles de millones ponen de manifiesto lo que las bases de datos relacionales no pueden soportar sin una reconfiguración continua, cuantificación e indexación en disco. TripAdvisor indexa más de 1.000 millones de opiniones de usuarios multimodales en Qdrant. HubSpot utiliza Qdrant para su asistente de IA Breeze. Una base de datos de uso general con un tipo de datos vectorial tiene dificultades a esa escala.

La narrativa sobre la «muerte» y el crecimiento de la categoría de bases de datos vectoriales son válidas en el segundo trimestre de 2026, pero definen partes diferentes del mismo mercado. Tu posición en la escala, la carga de trabajo y el espectro de implementación determinan qué argumento se aplica a tus decisiones de infraestructura este trimestre.

El mercado de las bases de datos vectoriales está creciendo. La cuestión es a qué segmento puede dirigirse cada proveedor.

La tesis de la trifurcación: un mercado que se divide en tres

El mercado de las bases de datos vectoriales no se está concentrando en un único ganador. Se están produciendo tres divisiones simultáneas en función de la escala, el tipo de carga de trabajo y el entorno de implementación. La mayoría de las decisiones arquitectónicas que se tomen en 2026 darán lugar a resultados erróneos, ya que los equipos solo están evaluando el número de vectores.

La trifurcación del mercado de las bases de datos vectoriales en función de la escala, la carga de trabajo y el despliegue

Escalabilidad: en qué aspectos destaca Postgres y cuáles son sus límites

Todos los principales proveedores de servicios en la nube a hiperescala y las bases de datos relacionales tradicionales ofrecen ahora búsqueda vectorial pura. PostgreSQL cuenta con pgvector y pgvectorscale; Oracle, con Database 26ai; Microsoft SQL Server ha añadido un tipo de datos vectorial; Amazon RDS utiliza pgvector; y Cloud SQL para MySQL de Google dispone de búsqueda por similitud. Las encuestas anuales a desarrolladores de Stack Overflow muestran que PostgreSQL ocupó el primer puesto entre las bases de datos desde 2023 hasta 2025.

Con menos de 50 millones de vectores, Postgres, junto con pgvector y pgvectorscale, admite cargas de trabajo de producción sin necesidad de un motor vectorial independiente. Para los equipos que ya utilizan Postgres, añadir la búsqueda vectorial con pgvector es tan sencillo como ejecutar el comando «CREATE EXTENSION vector;». TigerData comparó el rendimiento de pgvectorscale con el de Qdrant en el conjunto de datos Cohere Wikipedia de 50 millones (768 dimensiones), con un objetivo de recuperación del 99 % en una instancia AWS r6id.4xlarge. pgvectorscale obtuvo 471,57 consultas por segundo (QPS), frente a las 41,47 QPS de Qdrant, lo que supone una diferencia de rendimiento de 11 veces en una configuración de un solo nodo.

Postgres se impuso en cuanto a rendimiento, pero Qdrant ganó en latencia p95, con 36,73 ms frente a los 60,42 ms de pgvectorscale, y en tiempo de creación de índices, con 3,3 horas frente a 11,1 horas. Como señala Desmond Tan, nuestro vicepresidente de ingeniería:

A una escala de mil millones de vectores y con límites de latencia muy estrictos, una base de datos de uso general a la que se le añade un tipo vectorial no da la talla. Lo difícil nunca fue la búsqueda del vecino más cercano, sino el marco operativo, como la estabilidad de la recuperación ante actualizaciones continuas.

Los motores diseñados específicamente para este fin aumentan la velocidad de creación de índices, gestionan la fragmentación entre nodos, controlan la descarga de datos al disco y mantienen una latencia p95 predecible ante las escrituras simultáneas que exigen las cargas de trabajo vectoriales de más de 100 millones. NVIDIA creó un sistema de minería de datos multimodal en Milvus, indexando más de 10 000 millones de puntos de datos de sensores procedentes de flotas de prueba, y logró una reducción de costes de 30 veces sin necesidad de rediseñar la arquitectura. Cuando ajustas autovacuum y maintenance_work_mem para mantener estable la recuperación, tu carga de trabajo ya ha superado a Postgres con pgvector.

Carga de trabajo: los agentes de IA han desmentido la hipótesis de que el sistema está optimizado para la lectura

Se crearon bases de datos vectoriales específicas para los flujos de trabajo de «Generación Aumentada por Recuperación» (RAG) con un alto volumen de lecturas. En 2026, los agentes de IA realizan 10 veces más consultas que los humanos. Escriben con frecuencia y provocan un aumento excesivo del tamaño de los índices, picos de tráfico y presión por la multitenencia que los índices optimizados para la lectura no gestionan bien. Tal y como publicó en X un ingeniero de backend de eToro,

La cuestión para 2026 ya no es qué base de datos vectorial elegir, sino qué estrategia de recuperación necesita realmente la carga de trabajo. La mayoría de los fallos en producción se deben a que se intenta encajar todos los problemas en el mismo proceso sencillo de «recuperar y luego generar».

Las bases de datos vectoriales «Cloud-first» están dando respuesta a las cargas de trabajo con un alto volumen de escrituras mediante el escalado automático, el aislamiento nativo a nivel de fila y la transmisión en tiempo real. Sin embargo, el mercado también se está replanteando si la base de datos debería estar alojada en la nube.

Implementación: los proveedores de soluciones nativas en la nube de Axis no pueden hacer frente a

En los sectores que manejan datos sensibles, las representaciones vectoriales deben cumplir estrictas normas de cumplimiento según leyes como la Ley de IA de la UE, la Ley CLOUD de EE. UU., el Reglamento General de Protección de Datos (RGPD) y la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA). Gartner prevé que, para 2030, más del 75 % de las empresas europeas y de Oriente Medio repatriarán sus cargas de trabajo virtuales debido al riesgo geopolítico, frente a menos del 5 % en 2025. Los proveedores de servicios en la nube ofrecen certificados de cumplimiento normativo, pero mantener la base de datos en las propias instalaciones permite a los equipos ejercer un control directo sobre la gobernanza de los datos y reduce los puntos únicos de fallo que introduce la infraestructura en la nube.

La infraestructura adecuada para el segundo trimestre de 2026 depende del número de vectores, la idoneidad operativa y las limitaciones de implementación. En esta tabla se explica cómo tomar una decisión.

Pinecone: La paradoja de la moneda de veinticinco centavos

Pinecone está posicionando Nexus como la arquitectura de agentes que sustituye a RAG, basándose en una única prueba de rendimiento interna que nadie ha podido reproducir. Esa prueba no verificada, y no el lanzamiento en sí, es lo que determina si Nexus debe formar parte de tu infraestructura de agentes este trimestre.

Los ingresos de Pinecone cayeron de 27 millones de dólares en 2024 a 14 millones en 2025; Notion sufrió una pérdida de clientes, y The Information informó de que la empresa estaba barajando la posibilidad de venderse en agosto de 2025. Nueve meses después, el 4 de mayo de 2026, lanzaron Nexus, su producto más ambicioso hasta la fecha. Si estás ejecutando cargas de trabajo vectoriales en Pinecone, esa secuencia es el contexto en el que debes evaluar Nexus.

Nexus es el intento de Pinecone de avanzar en la IA agencial . Combina un compilador de contexto que genera artefactos vectoriales específicos para cada tarea a partir de información vectorial sin procesar procedente de bases de datos, y un recuperador modulable que proporciona dichos artefactos con citas por campo y resolución determinista de conflictos. El director ejecutivo de Pinecone, Ash Ashutosh, calificó el lanzamiento como un cambio arquitectónico:

RAG se diseñó para usuarios humanos. Nexus se diseñó para usuarios «agentes», ya que su lenguaje es muy diferente.

Tras el lanzamiento de Nexus, se presentó KnowQL, un lenguaje de consulta declarativo. Permite a los agentes de IA especificar la intención, la procedencia, el formato de los resultados, los límites de latencia y los requisitos de confianza sin tener que interpretar directamente los vectores sin procesar. Las pruebas internas de Pinecone con Nexus sobre los documentos presentados ante la SEC (formularios 10-K) indicaron que las tasas de finalización aumentaron del 50-60 % a más del 90 %, se redujo en un 95 % el uso de tokens en los modelos de lenguaje a gran escala (LLM) y se multiplicó por 30 la velocidad de ejecución de las tareas. Ninguno de estos resultados ha sido validado en implementaciones en producción.

El mecanismo de Nexus, que consiste en compilar el razonamiento antes de que se ejecute cualquier consulta y almacenar los resultados como artefactos reutilizables, es acertado desde el punto de vista conceptual. Arun Chandrasekaran, analista y vicepresidente de Gartner, lo describió como un paso significativo más allá de la simple recuperación: «A diferencia del RAG tradicional, que se basa en la búsqueda semántica pura en tiempo de ejecución, la compilación arquitectónica integra la lógica estructural en la capa de metadatos, lo que puede acelerar el tiempo de respuesta y proporcionar un mejor razonamiento.» Janakiram MSV se muestra crítico específicamente con KnowQL, argumentando que «KnowQL tiene que superar el listón de estandarización que superó SQL, y los estándares no se establecen por la simple declaración de un único proveedor.» 

Desmond está de acuerdo en que el principio de Nexus es sólido, aunque no nuevo, y lo define como «el almacenamiento en caché aplicado a la recuperación». En cuanto a la prueba de rendimiento con un único caso de prueba, es muy directo: «Antes de recomendar Nexus, necesitaría una reproducción independiente en un conjunto de pruebas no seleccionado de forma sesgada, una explicación clara del modo de fallo por artefactos obsoletos y una evaluación honesta del efecto de bloqueo». No se comprometería a destinar infraestructura de agentes a ello este trimestre porque «KnowQL es un lenguaje de consulta de un único proveedor, y el SQL se convirtió en un estándar por decisión de un comité, no por simple declaración».

Pinecone afirma que su motor vectorial da servicio a 9.000 clientes y 800.000 desarrolladores. La empresa fue pionera en la categoría de bases de datos vectoriales gestionadas en 2023 y alcanzó una valoración de 750 millones de dólares tras una ronda de financiación de serie B de 100 millones de dólares. Basaron su mensaje fundacional en RAG y, posteriormente, lanzaron Nexus como el producto que va más allá de esta tecnología. Sin embargo, Nexus sigue dependiendo de la base de datos vectorial de Pinecone en cuanto a velocidad de recuperación, almacenamiento y escalabilidad. Ash confirmó que «los vectores siguen almacenándose y gestionándose mediante la base de datos vectorial de Pinecone». La afirmación del mercado de que la infraestructura de la era RAG ha quedado obsoleta no se sostiene mientras los sistemas agenticos sigan basándose en ella. 

La noticia de la venta aún no se ha confirmado y las mejoras en los índices de referencia no se han validado. Pero lo que sí puedes controlar es tu proceso de incrustación, independientemente de lo que suceda a continuación. Documenta hoy mismo el modelo, la versión, las dimensiones y la estrategia de segmentación. Mantén la portabilidad de tu sustrato de recuperación, de modo que la capa de compilación siga siendo una optimización opcional que puedas sustituir.

¿Son las bases de datos vectoriales el sustrato adecuado para la memoria de los agentes?

Las bases de datos vectoriales gestionan bien un tipo de memoria de los agentes, pero su rendimiento se ve mermado en el otro. Obligar a un único tipo de índice a satisfacer diferentes necesidades de recuperación es la causa por la que fracasan la mayoría de las arquitecturas de IA en entorno de producción.

La memoria del agente ejecuta dos cargas de trabajo distintas. La recuperación semántica de un solo paso sobre una biblioteca de documentos estable requiere muchas lecturas y se indexa por lotes. Eso es RAG, y los índices HNSW e IVF lo gestionan bien. La segunda parte es la memoria operativa del agente. Implica escrituras frecuentes, recuperación iterativa, extracción de hechos y resolución de entidades. Un índice optimizado para la lectura pierde rendimiento con esta carga de trabajo.

Ben Bartholomew, de Hindsight, tenía en parte razón cuando dijo: «“La memoria de agente equivale a una base de datos vectorial” se ha convertido en una especie de sabiduría popular… La memoria de agente es otra cosa, y tratar ambos conceptos como si fueran el mismo problema es lo que provocó el mal valor por defecto en primer lugar». La tabla siguiente muestra cómo difieren los patrones de consulta de RAG y de los agentes en cinco dimensiones de recuperación.

Anthropic eliminó la búsqueda vectorial de Claude Code en mayo de 2025 y la sustituyó por grep. Cursor, Windsurf, Cline, Devin y Sourcegraph Amp siguieron este ejemplo, abandonando la similitud vectorial en favor de la búsqueda basada en herramientas.

El equipo de producto de Weaviate dedicó dos semanas a integrar Engram, su producto de memoria basado en vectores, con Claude Code a través del Protocolo de Contexto de Modelos (MCP). Claude lo ignoró por completo, explicando: «Mi valor por defecto es MEMORY.md porque siempre está cargado: latencia cero, cero llamadas a herramientas, garantizado en contexto. No hay motivo para recurrir a una herramienta externa cuando el almacén de memoria principal ya está presente». Un agente de programación recorre un grafo de dependencias, importaciones, llamadas a funciones y definiciones de tipos. Esa carga de trabajo exige determinismo y coincidencias exactas, más que similitud semántica. 

El equipo de Hindsight utiliza un enfoque multistrategia que combina y clasifica cuatro motores de recuperación paralelos en PostgreSQL: búsqueda semántica, recuperación basada en entidades, filtrado temporal y recorrido de grafos. En el banco de pruebas LongMemEval, este enfoque híbrido alcanzó una precisión del 94,6 % , frente al 49 % del sistema de Mem0, basado principalmente en vectores. La búsqueda con grep y la recuperación híbrida ofrecen mejores resultados que la búsqueda vectorial pura para agentes de programación y colecciones de documentos que se actualizan con frecuencia y que no superan los 10 millones. Mantener un índice vectorial sincronizado con un código fuente activo requiere una reincorporación frecuente, lo cual resulta costoso a gran escala y retrasa la actualidad de los resultados de la recuperación.

El argumento de Hindsight es que una base de datos vectorial carece de la percepción temporal, la separación de responsabilidades y las capacidades de resolución de conflictos que exige la memoria de un agente en funcionamiento. El problema radica en aplicar la búsqueda vectorial a una restricción del agente que no es la adecuada.

Herbie Turner, director técnico de &AI, confirmó que Qdrant es «la referencia» para su agente de patentes, que gestiona más de mil millones de vectores. Reddit sigue procesando datos vectoriales a escala de mil millones en Milvus. Los marcos de memoria de IA, como Mem0, utilizan bases de datos vectoriales como infraestructura subyacente de recuperación, combinadas con un gráfico de conocimiento las relaciones entre entidades. Las bases de datos vectoriales conservan datos de dominio a largo plazo entre sesiones. Para bases de conocimiento grandes y heterogéneas, en las que la precisión de la recuperación determina los resultados empresariales y los resultados omitidos resultan costosos, la búsqueda vectorial sigue siendo el enfoque adecuado. También es la estrategia de recuperación más práctica para consultas en lenguaje natural en sistemas de búsqueda de documentos no estructurados.

Andre Zayarni, director ejecutivo de Qdrant, explicó la diferencia en el volumen de consultas que hace que las bases de datos vectoriales sean relevantes:

Los seres humanos realizan unas cuantas consultas cada pocos minutos. Los agentes realizan cientos o incluso miles de consultas por segundo, simplemente para recabar información que les permita tomar decisiones.

Los agentes desperdician hasta el 85 % de la capacidad de cálculo en la recuperación del contexto. Las bases de datos vectoriales hacen que esa recuperación sea rápida y precisa a gran escala.

Memoria de agentes de tres capas

Los agentes de codificación y el estado de trabajo mutable son propios de grep, pero la búsqueda vectorial sigue siendo la infraestructura adecuada para la recuperación de conocimiento a gran escala.

El entorno de implementación que la categoría olvidó

La mayoría de las comparativas de bases de datos vectoriales publicadas en el primer trimestre de 2026 dan por sentada una conectividad constante a la nube. Esa suposición excluye las plantas de fabricación, las redes hospitalarias, los sistemas de defensa aislados físicamente y cualquier entorno en el que los datos no puedan salir del edificio. En la actualidad, hay tres factores que hacen que esa brecha sea imposible de ignorar. Nuestra directora técnica, Emma McGrattan, explica cómo se ha llegado a esta situación: «La primera ola de desarrollo de bases de datos vectoriales estuvo impulsada por equipos de IA nativos de la nube (investigadores, startups, laboratorios de hiperescaladores) que trabajaban en entornos en los que los datos podían circular libremente y se daba por sentada la conectividad».

Repatriación de servicios en la nube para la IA empresarial

El 86 % de los directores de sistemas de información (CIO) tenía previsto trasladar sus cargas de trabajo de IA fuera de la nube pública en 2025, debido a los costes de la nube, la normativa sobre soberanía de datos, los requisitos de latencia y la dependencia de un único proveedor. El informe «State of the Cloud 2026» de Flexera revela que el 23 % ya ha completado ese traslado. Los proveedores de bases de datos que dan prioridad a la nube están siguiendo a las empresas en su regreso a las instalaciones propias.

Amazon lanzó RDS on Outposts para su implementación en instalaciones propias y en centros de coubicación. Oracle lanzó la base de datos 26ai para su implementación en instalaciones propias en plataformas Linux x86-64 en enero de 2026. Cada lanzamiento fue una respuesta directa a la tendencia de las empresas de recuperar las cargas de trabajo dentro de los límites de su propia infraestructura. Desmond prevé que, en el segundo semestre de 2026, «la pregunta de si “la base de datos vectorial puede ejecutarse dentro de los límites de la infraestructura” dejará de ser una casilla más que marcar y se convertirá en el principal criterio de selección. Los proveedores nativos de la nube no pueden adaptar esto a posteriori; es una cuestión de arquitectura». 

Soberanía de los datos

El RGPD restringe la salida de datos personales del Espacio Económico Europeo (EEE). Las transferencias de datos fuera del EEE requieren las cláusulas contractuales tipo (SCC) de la Comisión Europea, el cifrado tanto en reposo como en tránsito, controles de acceso basados en roles y una evaluación documentada del impacto de la transferencia.

La HIPAA exige medidas de seguridad técnicas para la información sanitaria protegida (PHI) en formato electrónico. La Ley de IA de la UE, que entrará en vigor el 2 de agosto de 2026, exige una gobernanza de datos documentada, con multas para los sistemas de IA de alto riesgo que pueden alcanzar los 35 millones de euros o el 7 % de la facturación global anual. Ninguna de estas leyes exige explícitamente la residencia de los datos, pero estos deben cumplir la legislación local independientemente de dónde se encuentren. Por eso, el 95 % de los altos ejecutivos considera ahora que la IA soberana es una prioridad fundamental. Mantener los datos dentro de su perímetro de seguridad es la vía práctica para cumplir con la normativa. Como señaló Emma, «incorporar la soberanía y la gobernanza en sistemas que no han sido diseñados para ello resulta caro, lento y, a menudo, incompleto».

Física

La latencia de la red no es un problema de configuración. Incluso dentro de una misma región de la nube, el tiempo de ida y vuelta añade entre 20 y 80 ms antes de que comience cualquier proceso de cálculo. Si a esto le sumamos el tiempo de procesamiento de la aplicación, la latencia del modelo integrado y el retraso de propagación, la búsqueda vectorial en la nube introduce un umbral mínimo de latencia que ninguna optimización puede eliminar.

Como dijo Emma,

Una búsqueda vectorial en la nube bien optimizada que devuelva resultados en 20 ms sigue siendo cuatro veces demasiado lenta para la detección de fallos industriales o la clasificación de escenas en vehículos autónomos. Si necesitas una recuperación inferior a 5 ms, la nube queda descartada, independientemente de cualquier otro factor. Las leyes físicas del tiempo de ida y vuelta de una red no se pueden eludir.

El Centro Médico Asan (AMC) ha implantado el primer sistema privado de recuperación de conocimientos de Corea para el tratamiento de la sepsis, que funciona íntegramente en los servidores locales del hospital, dentro de una red cerrada. El sistema proporciona pruebas de diagnóstico de la sepsis y directrices sobre el uso de antibióticos con mayor rapidez, y mantiene los datos confidenciales de los pacientes dentro de los límites del hospital. El AMC es un ejemplo de las limitaciones de hardware a las que se enfrenta cualquier implementación en el borde de la red.

Los dispositivos con menos de 4 GB de almacenamiento admiten entre 10 000 y 1 millón de vectores sin necesidad de poda ni organización por niveles. Los motores nativos de la nube se diseñaron teniendo en cuenta los presupuestos de RAM de la nube, y esa suposición deja de ser válida en el hardware periférico.

Restricciones de implantación por sector y entorno

La tabla siguiente muestra cómo se aplican estas restricciones en los modelos de implementación en la nube, en las propias instalaciones y en el perímetro.

La implementación en la nube sigue siendo la opción que ofrece menos obstáculos para más de 100 millones de cargas de trabajo que requieren una latencia inferior a 100 ms y una conectividad permanente.

Las cargas de trabajo con conectividad intermitente que exigen una latencia inferior a 5 ms y el procesamiento local de datos requieren una implementación en el borde o en las propias instalaciones. Como señaló Emma: «El ecosistema de bases de datos vectoriales de código abierto, aunque es excelente para implementaciones en la nube, sencillamente no está optimizado para las limitaciones que importan en el perímetro: espacio de memoria limitado, conectividad intermitente, ajuste del rendimiento específico para el hardware, latencia local predecible y la capacidad de funcionar de forma totalmente aislada». Ni siquiera los proveedores que están adoptando modelos híbridos han logrado salvar esa brecha. Zilliz Cloud lanzó «Bring Your Own Cloud Infrastructure» (BYOC-I) en abril de 2025, pero sigue requiriendo acceso a la nube.

Antes de elegir un modelo de implementación, responde a estas tres preguntas:

1. ¿Cuál es tu modelo de conectividad?
2. ¿Tu carga de trabajo requiere una latencia inferior a 5 ms?
3. ¿Existe algún requisito relativo a la residencia de los datos o a la separación física?

Si alguna respuesta apunta a que no se dispone de una conectividad de red constante, los proveedores de soluciones nativas en la nube no podrán gestionar tu carga de trabajo. Actian VectorAI DB está diseñado precisamente para hacer frente a las limitaciones de red. VectorAI DB se ejecuta en NVIDIA Jetson, Raspberry Pi, servidores industriales de borde, centros de datos hospitalarios e instalaciones aisladas físicamente. Ofrece 1.040 QPS con 1 millón de vectores y una latencia p99 de 12,7 ms en hardware local. Funciona totalmente sin conexión y, opcionalmente, se sincroniza cuando se restablece la conectividad.

Benchmark Trust en 2026: cómo interpretar las cifras

Las pruebas comparativas de los proveedores te indican cómo funciona una base de datos en las condiciones que el propio proveedor ha elegido para realizar las pruebas. Antes de basarte en una cifra para tomar una decisión sobre la infraestructura en el segundo trimestre de 2026, debes saber qué es lo que mide realmente.

Qdrant publica el «vector-db-benchmark», Weaviate es propietaria de los «ANN-benchmarks», Zilliz Cloud es propietaria de «VDBBench», TigerData ha publicado su prueba de rendimiento «pgvectorscale» utilizando una bifurcación de los «ANN-benchmarks», y Redis publica sus propios conjuntos de pruebas de rendimiento.

La mayoría de las pruebas de rendimiento evalúan índices predefinidos, conjuntos de datos estáticos y configuraciones de bases de datos obsoletas. Ninguna de esas condiciones reproduce las configuraciones de producción ni las cargas de trabajo de los agentes. La página de pruebas de rendimiento de Qdrant afirma explícitamente: «¿Tenemos sesgos? Probablemente, sí». Enuna publicación de LinkedIn en la que se criticaban los resultados de las pruebas de rendimiento de TigerData, Qdrantañadió: «Nadie publica una prueba de rendimiento en la que su producto no destaque. Nosotros hacemos lo mismo». 

En la prueba comparativa entre pgvectorscale de TigerData y Qdrant, se procesó el conjunto de datos Cohere Wikipedia 50M (768 dimensiones) con un objetivo de recuperación del 99 % en una instancia AWS r6id.4xlarge. La configuración utilizó 16 vCPU, 128 GB de RAM y un SSD NVMe conectado localmente de 950 GB. Con latencias de consulta inferiores a 100 ms, pgvectorscale obtuvo 471,57 QPS frente a los 41,47 QPS de Qdrant.  Qdrant se impuso en el tiempo de creación del índice, con 3,3 horas frente a las 11,1 horas de pgvectorscale, y en la latencia de cola con un 90 % de recuperación, logrando una latencia p95 un 58,6 % menor y una latencia p99 un 63,2 % menor.

Qdrant argumentó que la prueba no reflejaba casos de uso en producción que implicaran filtros de metadatos, búsquedas híbridas con vectores dispersos o búsquedas multivectoriales. También señaló que TigerData no había optimizado Qdrant para su propia arquitectura, mientras que pgvectorscale utilizaba StreamingDiskANN y la cuantificación binaria estadística (SBQ). La diferencia de rendimiento se reduce cuando cambia cualquiera de estas condiciones.

La crítica de Qdrant señala precisamente lo que la mayoría de las pruebas comparativas de bases de datos vectoriales pasan por alto. VDBBench 1.0, de Zilliz Cloud, evalúa la ingesta continua de datos, el rendimiento de las búsquedas, la variación del rendimiento bajo cargas simultáneas de lectura y escritura, y la selectividad de los filtros de metadatos. Esas son las condiciones a las que se enfrentará tu sistema de producción.

Cada cifra de referencia que utilices debería responder primero a estas cinco preguntas:

1. ¿Quién publicó el índice de referencia?
2. ¿Con qué hardware, parámetros de índice y configuración de concurrencia se ejecutó la prueba de rendimiento?
3. ¿Qué indicadores se seleccionaron y cuáles se excluyeron?
4. ¿Se ajusta la carga de trabajo a tu caso de uso?
5. ¿Es reproducible y ha sido verificado de forma independiente el índice de referencia?

Cinco preguntas para evaluar cualquier prueba de rendimiento de una base de datos vectorial

Como dice Desmond: «Si no se especifican la capacidad de recuperación, el hardware y la concurrencia, descarta la cifra». La prueba de rendimiento más fiable es aquella que se ejecuta con tus propios datos, hardware y patrones de consulta. Si tu equipo ejecuta cargas de trabajo vectoriales en Milvus, actualiza a la versión 2.5.27+ o 2.6.10+ antes de comparar cualquier resultado de pruebas de rendimiento. Esta actualización corrige las vulnerabilidades de autenticación CVE-2026-26190 (CVSS 9,8) y CVE-2025-64513 (CVSS 9,3).

El mapa de presencia en la comunidad

El mercado de las bases de datos vectoriales ha alcanzado unos patrones claros en cuanto a adopción, precios y adecuación a los casos de uso en el segundo trimestre de 2026.

Milvus lidera el interés de la comunidad de código abierto con más de 44 000 estrellas en GitHub, seguido de Qdrant con más de 32 000, ChromaDB con más de 28 000, Weaviate con más de 16 000 y LanceDB con más de 10 000.

El número de estrellas refleja el interés de la comunidad, no el uso en la producción

LanceDB es la que presenta la tasa de crecimiento más elevada en cuanto a presencia en la mente de los usuarios, pasando del 6,7 % al 9,6 % interanual tras cerrar una ronda de financiación de serie A de 30 millones de dólares en junio de 2025. ChromaDB descendió del 15,6 % al 13,4 % durante el mismo periodo, ya que pgvector acaparó la atención de los equipos que ya utilizaban Postgres.

Evolución de la popularidad de LanceDB frente a Chroma

Weaviate, Milvus, Qdrant y LanceDB se pueden alojar de forma autónoma de manera gratuita. Solo se paga por la capacidad de cálculo que se utilice para ejecutarlos. Es en sus planes gestionados donde el panorama de costes cambia.

Weaviate Cloud sustituyó su plan «Serverless», de 25 dólares al mes, por el plan «Flex», de 45 dólares al mes , el 27 de octubre de 2025, lo que supone un aumento del 80 %. El plan «Plus» cuesta 280 dólares al mes y el plan «Premium», 400 dólares al mes. Cada nivel incluye tarifas basadas en el uso que cubren las dimensiones de los vectores, el almacenamiento y el tiempo de retención de las copias de seguridad.

Zilliz Cloud ofrece un plan gratuito con cinco colecciones, 5 GB de almacenamiento y 2,5 millones de vCU al mes. El plan «Dedicated Standard» tiene un coste de 126 dólares al mes en recursos de computación. El plan «Dedicated Enterprise» cuesta 196,56 dólares al mes, con un coste de almacenamiento de 0,025 dólares por GB y tarifas de transferencia de datos que se facturan por separado.

El plan gratuito de Qdrant Cloud incluye un clúster de un solo nodo con 1 GB de RAM, 0,5 vCPU y 4 GB de disco. El plan Estándar cobra por la potencia de cálculo, el consumo de memoria, el almacenamiento de copias de seguridad y los tokens de inferencia de modelos. El plan Premium requiere una conversación directa con el equipo de ventas. LanceDB Cloud fija el precio del almacenamiento de objetos en 0,02 dólares por GB al mes, mientras que los precios del plan Enterprise se establecen mediante un compromiso anual personalizado.

Pinecone presentó el plan «Builder», de 20 dólares al mes, el 6 de mayo de 2026, tras haber lanzado en julio de 2025 el plan «Standard», de 50 dólares al mes. OpenMetal documentó que el precio inicial de 50 dólares aumentaba hasta los 380 dólares y, posteriormente, hasta los 2.847 dólares a medida que crecía el uso. El plan «Enterprise» tiene una cuota mínima mensual de 500 dólares a partir de junio de 2026.

El consenso sobre los casos de uso de las principales bases de datos vectoriales en 2026 se corresponde con la escala y las preferencias operativas. Pinecone elimina la sobrecarga operativa para los equipos que desean una infraestructura gestionada. pgvector da servicio a equipos de Postgres con entre 10 y 50 millones de vectores. Milvus gestiona las consultas distribuidas y la gestión de fragmentos para implementaciones a escala de miles de millones. Weaviate se adapta a aplicaciones que necesitan búsqueda híbrida nativa y modelos de incrustación integrados. Qdrant ofrece búsqueda vectorial componible y filtros basados en JSON. ChromaDB abarca prototipos RAG y herramientas internas locales. LanceDB resulta muy adecuado para aplicaciones integradas y sistemas de IA multimodales.

Mapa de adecuación de casos de uso de la base de datos vectorial para el segundo trimestre de 2026

El marco de decisión para este trimestre

Estas tres auditorías determinan qué base de datos de vectores se adapta mejor a tu pila tecnológica. Realízalas en el orden indicado antes de elegir cualquier infraestructura para tu aplicación o agente.

Auditoría 1: Recuento de vectores

El número de vectores determina los límites de lo que merece la pena evaluar.

• <10M vectors on Postgres: Use pgvector. It keeps vector data adjacent to relational data without managing a new database engine. You get ACID transactions, hybrid search, and one security model in the same system. 
• Vectores de 10 M a 50 M: Compara el rendimiento de Qdrant autohospedado y pgvectorscale con tus datos antes de tomar una decisión. Qdrant ofrece búsqueda vectorial con filtrado JSON basado en la carga útil. pgvectorscale mejora el rendimiento de pgvector a escala media gracias a StreamingDiskANN. 
• >50 millones o multitenencia a escala de agente: Utiliza la arquitectura distribuida y acelerada por GPU de Milvus para escalar horizontalmente o crear un almacén vectorial personalizado basado en el comportamiento de tu agente. 

Auditoría 2: Restricción de implementación

El lugar donde se ejecuta tu aplicación determina qué bases de datos siguen siendo viables. Si tu carga de trabajo requiere:

• Latencia inferior a 5 ms: Elimina Pinecone. Una arquitectura cliente-servidor en dispositivos periféricos o entornos sin conexión tendrá dificultades para cumplir con ese tiempo de respuesta. Localiza el proceso de integración y da prioridad a las bases de datos que se ejecutan en el propio dispositivo y en las instalaciones. Comprueba si se ajustan a la capacidad de memoria de tu hardware.
• Cumplimiento de los requisitos de separación de aire: Elimina las bases de datos gestionadas en la nube. Estas requieren acceso a la red y validación remota de licencias. Utiliza bases de datos autohospedadas como VectorAI DB y Qdrant. El binario de Qdrant, escrito en Rust, es ligero, y su imagen de Docker se exporta como un archivo .tar . VectorAI DB está diseñada para cargas de trabajo vectoriales en implementaciones con aislamiento físico.
• Residencia estricta de los datos: Audita todo el ciclo de vida de tus datos. Confirma dónde se almacenan los datos de los clientes, la telemetría y los registros del sistema, por dónde circulan durante su tránsito y dónde residen las copias de seguridad. Verifica que el proveedor de bases de datos en la nube cuente concentros de datos físicamente aisladosdentro de tus límites de residencia. Da prioridad a bases de datos locales como Weaviate y VectorAI DB, que se ejecutan a través de Docker,para mantener un control total sobre los datos. Ambas bases de datos admiten la multitenencia para cumplir con los requisitos de residencia de datos.

Auditoría 3: Tipo de carga de trabajo

Tu patrón de recuperación determina qué arquitectura de índice es la más adecuada.

• Recuperación en una sola búsqueda: Utiliza almacenes de vectores compatibles con HNSW para RAG, búsqueda semántica y sistemas de recomendación. Están optimizados para ofrecer una precisión de recuperación «top-K» y una baja latencia de lectura. 
• Memoria de agentes con gran volumen de escritura y vectores de menos de 10 millones: Utiliza Postgres con pgvector. El índice IVFFlat de pgvector crea y actualiza los índices más rápidamente con una sobrecarga mínima de la CPU, y Postgres escribe las nuevas representaciones vectoriales en un registro de escritura anticipada (WAL) para que los agentes no pierdan el hilo del contexto de la conversación activa. Integra Mem0 para gestionar la compresión semántica y el movimiento de memoria entre el contexto a corto plazo del agente y Postgres. 
• Memoria de agente con gran volumen de escritura para más de 10 millones de vectores: Las cargas de trabajo de agentes a gran escala requieren un alto rendimiento de escritura sin pausas para la reconstrucción de índices. Utiliza la indexación en tiempo real de Milvus para escribir vectores de forma continua, mientras que su compactación en segundo plano fusiona automáticamente los segmentos de datos para mantener el rendimiento de las consultas. 

El diagrama de flujo que aparece a continuación agrupa las tres auditorías en una ruta de decisión que puedes seguir en función de tu propia pila. 

Diagrama de flujo para la elección de bases de datos vectoriales en 2026

Antes de realizar cualquier migración, haz estas tres cosas:

1. Ejecuta VDBBench 1.0 con tu propia carga de trabajo y tu propio hardware.
2. Documenta tu proceso de integración si tu carga de trabajo se ejecuta en Pinecone.
3. Actualiza a las versiones 2.5.27+ o 2.6.10+ antes de realizar cualquier cambio arquitectónico en Milvus.

Conclusión

El sector de las bases de datos vectoriales no está en declive. El segmento de escalabilidad por debajo de los 50 millones de vectores se está consolidando en torno a Postgres. Por encima de ese umbral, los motores diseñados específicamente para este fin siguen ofreciendo un rendimiento y una capacidad operativa que las bases de datos de uso general no pueden igualar.

Los agentes están impulsando una revisión de la arquitectura de recuperación que ningún proveedor ha resuelto aún por completo. Las cargas de trabajo que no pueden enviar datos a un servidor en la nube siguen siendo el problema menos abordado en este ámbito.

La decisión que tomes este trimestre no tiene por qué esperar a que el mercado se estabilice. Tu recuento de vectores, tus limitaciones de despliegue y tu patrón de recuperación ya apuntan a una respuesta. Realiza las tres auditorías y actúa en función de lo que revelen.

Si tus auditorías revelan que el despliegue se realiza en el perímetro, en instalaciones propias o en un entorno aislado (air-gapped), ese es el segmento al que la mayoría de los proveedores de soluciones nativas de la nube no pueden dar servicio con su arquitectura actual. VectorAI DB está diseñado para hacer frente a esas limitaciones. Descubre lo que los desarrolladores ya han creado con esta herramienta en los sectores de la sanidad y la industria manufacturera.

Acerca del autor

Acerca de Tahiya Chowdhury

Tahiya Chowdhury es la directora de producto de Actian Zen y VectorAI DB, donde dirige la estrategia de la plataforma de datos en el borde más sólida del sector. Gracias a su experiencia en MongoDB y Goldman Sachs, Tahiya se especializa en crear productos que se sitúan en la intersección entre las necesidades empresariales a gran escala y la agilidad de los desarrolladores modernos. Le apasiona eliminar la complejidad de la infraestructura de datos, lo que permite a los equipos de ingeniería pasar más rápidamente del prototipo a la producción.