Elegir una base de datos vectorial para RAG: comparación de ocho opciones.

Elegir una base de datos vectorial para RAG se reduce a unas pocas preguntas clave sobre el tamaño, el filtrado, el modelo de alojamiento y cuántas operaciones puede manejar su equipo. Aquí está la versión breve antes de entrar en detalles: Chroma y pgvector son adecuados para proyectos pequeños. Qdrant y Milvus son las opciones habituales para entornos de producción autohospedados. Pinecone es la opción completamente gestionada. Si ya utiliza Postgres en su stack, pgvector no supone ningún costo adicional, y si solo desea una configuración local lista en minutos, Chroma se instala con un único comando pip.

Los motores de código abierto como Qdrant, Milvus y Weaviate pueden competir con las plataformas de pago en términos de capacidad de recuperación de datos y latencia, y cada uno ofrece una opción gratuita de autohospedaje además de una versión pagada en la nube. Otro dato importante que vale la pena recordar: al combinar la recuperación de vectores densos con búsquedas por palabras clave basadas en BM25 disperso, la tasa de Recall@10 ha aumentado de aproximadamente el 78 % al 91 % en pruebas de rendimiento en entornos reales, y por eso la búsqueda híbrida está presente en tantas de las opciones que se presentan a continuación.

Las bases de datos vectoriales son la capa de recuperación detrás de la mayoría de las aplicaciones de IA generativa. Permiten a una empresa basar un modelo de lenguaje en sus propios datos, de modo que las respuestas sean precisas y específicas para ese dominio. A medida que aumenta la cantidad de datos no estructurados, la recuperación se convierte en el principal cuello de botella para garantizar la calidad, y elegir adecuadamente implica comprender los algoritmos de indexación, el comportamiento del filtrado y el costo de la infraestructura necesaria.

Qué hace realmente una base de datos vectorial

Una base de datos vectorial almacena embeddings de alta dimensión y clasifica las filas almacenadas según cuán cerca se encuentran de un vector de consulta, utilizando similitud coseno, producto escalar o distancia L2. Un motor relacional busca tokens exactos, mientras que BM25 evalúa la superposición de términos. Una búsqueda vectorial puede devolver documentos sobre “coches asequibles” para la consulta “automóvil barato”, ya que ambas frases se ubican cerca una de la otra en el espacio de embeddings.

Hay un problema. La búsqueda exacta de k vecinos más cercanos tiene un costo de O(N·d) por consulta, lo que deja de ser práctico cuando se superan unos cientos de miles de vectores. Las bases de datos vectoriales solucionan esto aceptando una pequeña pérdida en la capacidad de recuperación a cambio de índices de vecinos más cercanos aproximados (ANN) que responden en un tiempo aproximadamente logarítmico.

Qué medir antes de elegir

Los equipos que omiten la evaluación suelen toparse con cuellos de botella en la producción. Hay cuatro áreas que merecen ser analizadas.

Calidad de recuperación y latencia. Recall@K indica con qué frecuencia el sistema encuentra las coincidencias realmente mejores entre sus primeros K resultados. Un mayor nivel de recall significa que el modelo recibe la mejor información disponible. La latencia, expresada en milisegundos, es igualmente importante, y los ingenieros se fijan en los valores p95 o p99, ya que reflejan el extremo más lento de la experiencia de los usuarios.

Filtrado de metadatos. A menudo es necesario restringir una consulta mediante atributos estructurados. Una búsqueda de “política de la empresa” podría requerir que solo se muestren documentos posteriores a una fecha determinada o pertenecientes a un departamento específico. Un buen filtrado evita que los registros irrelevantes o no autorizados aparezcan en los resultados. Las bases de datos con filtrado previo suelen ser mejores, ya que descartan los registros no deseados antes de que comience la búsqueda vectorial, lo que protege la precisión.

Adecuación al ecosistema. Una base de datos resulta más útil cuando funciona bien con el resto de la stack de IA. Los conectores para LangChain y LlamaIndex acortan el tiempo necesario para crear un pipeline RAG funcional. Las bibliotecas de cliente en varios idiomas y el soporte para AWS, GCP y otras nubes determinan qué tan sin problemas se integra en el software empresarial existente.

Preparación operativa. Esto abarca si el sistema puede resistir un entorno de producción exigente:

• Escalabilidad, es decir, la capacidad de manejar miles de millones de vectores y un alto tráfico de consultas.
• Aislamiento entre usuarios en aplicaciones multiinquilino.
• Conformidad con estándares como SOC 2, HIPAA y GDPR.
• Observabilidad, para poder monitorear el rendimiento de la búsqueda y el uso de recursos.

Opciones gratuitas y de código abierto

Los motores de código abierto le permiten gestionar su propia infraestructura y evitar costos recurrentes de suscripción. Los motores que se detallan a continuación están ordenados aproximadamente de los más ligeros a los más pesados.

Chroma

Chroma es una base de datos de incrustación diseñada para agilizar el trabajo de los desarrolladores. Representa el camino más corto desde un repositorio vacío hasta un prototipo funcional de RAG, y muchas personas la utilizan como su primer almacén de vectores. Es adecuada para hackatones, desarrollo local y experimentos rápidos donde la facilidad de uso es más importante que la escala distribuida.

Lo que ofrece: una pequeña API en Python que permite pasar de pruebas locales temporales a un modo cliente-servidor persistente, almacenamiento local respaldado por SQLite, lo que evita la necesidad de configurar un servidor de base de datos, y funciones de incrustación integradas que convierten texto en bruto en vectores al insertarlo, utilizando por defecto modelos como all-MiniLM-L6-v2. Se conecta con LangChain, LlamaIndex, OpenAI y Hugging Face.

Por un lado, la instalación es sencilla con pip install chromadb, la conversión de texto a vectores se realiza sin código adicional, y al ejecutarse localmente se tiene control total sobre los datos y la infraestructura. Por otro lado, carece de las características de seguridad y multiarrendatario que necesitan los entornos empresariales estrictos, y no puede competir con los sistemas distribuidos diseñados específicamente cuando los datos superan unos pocos millones de vectores.

La base de datos principal es gratuita bajo licencia Apache 2.0, y ahora existe una versión en la nube alojada para escalar en entornos de producción.

Milvus

Milvus es una base de datos vectorial altamente distribuida y nativa de la nube que separa el procesamiento del almacenamiento. Está dirigida a organizaciones que manejan volúmenes extremos de datos, con cientos de millones o miles de millones de vectores, donde la escalabilidad horizontal es obligatoria y no opcional.

Su arquitectura divide los nodos de datos, los nodos de consulta y los nodos de índice. Soporta muchos tipos de índices, incluidos HNSW, IVF y DiskANN, lo que permite ajustarlo a hardware específico, y cuenta con un sistema de indexación y búsqueda acelerado por GPU de gran eficacia. Se pueden añadir o eliminar nodos en tiempo real sin interrupciones.

Fortalezas: los conjuntos de datos a escala de mil millones se comportan de manera predecible sin picos excesivos en la latencia p99; el aislamiento estricto de los nodos permite que los cálculos se realicen exactamente donde lo requiera la carga de trabajo; además, cuenta con una amplia comunidad de código abierto, abundante documentación y plugins. Debilidades: desplegar, ajustar y ejecutar el sistema basado en Kubernetes requiere un verdadero esfuerzo de ingeniería, y para una aplicación RAG sencilla, los componentes adicionales como etcd y Kafka suponen una sobrecarga innecesaria.

El motor está disponible gratuitamente bajo licencia Apache 2.0. Zilliz, la empresa detrás de él, ofrece servicios de hosting gestionado desde 155 dólares al mes.

Qdrant

Qdrant es un motor de búsqueda vectorial de código abierto escrito en Rust, y sus prioridades son la seguridad de la memoria, el rendimiento y un filtrado de datos muy eficaz. Los equipos que buscan velocidad y fiabilidad suelen optar por él, especialmente para aplicaciones RAG con filtros de metadatos avanzados, puntuación personalizada y presupuestos de latencia estrictos.

Detrás de escena se encuentra un motor de almacenamiento en Rust llamado Gridstore, optimizado para cargas de trabajo vectoriales. Un diseño de búsqueda modular permite que una sola consulta combine vectores densos, vectores dispersos y filtros de metadatos. El filtrado se aplica dentro del grafo durante el recorrido HNSW, lo que evita las disminuciones en la precisión que ocurren al filtrar después de la búsqueda. También existe Qdrant Edge, una versión ligera e integrada para dispositivos móviles y robótica.

La latencia típica de p50 ronda los 4 a 5 ms, el filtrado mantiene su precisión incluso bajo estrictas limitaciones, y la licencia (Apache 2.0) es permisiva. Las compensaciones: contribuir al núcleo de Rust implica una curva de aprendizaje más pronunciada, y obtener el mejor rendimiento de HNSW requiere ajustes cuidadosos de la memoria y los índices.

La versión de código abierto es gratuita. Qdrant Cloud ofrece una versión gestionada gratuita con 1 GB de almacenamiento, además de clústeres de pago basados en el uso.

Weaviate

Weaviate es una base de datos de código abierto nativa para IA, organizada en torno a objetos similares a grafos, que combina varios estilos de búsqueda y tipos de datos en una sola experiencia de consulta. Es la opción adecuada cuando se necesita una búsqueda híbrida avanzada, relaciones complejas entre objetos y un flujo de trabajo de IA integrado en la base de datos.

Combina de forma nativa una alta similitud con el ranking de palabras clave BM25. Los módulos de vectorización se conectan a OpenAI, Cohere y Hugging Face para incrustar el texto por usted. Los datos se almacenan en un esquema basado en clases orientado a las relaciones, e incluye aislamiento y replicación multiusuario.

Las ventajas son menos código genérico, ya que la conversión de texto a vector se realiza dentro de la base de datos; parámetros híbridos ajustables que equilibran la precisión exacta de las palabras clave con una amplia recuperación semántica; y respuestas estables en milisegundos incluso con cientos de millones de objetos. Las desventajas son la fricción inicial para adaptarse a su esquema basado en clases y un consumo de recursos mayor que las opciones incrustadas.

El software es gratuito bajo licencia BSD-3. Weaviate Cloud ofrece planes gestionados sin servidor desde 45 dólares al mes.

pgvector para PostgreSQL

La extensión pgvector convierte a PostgreSQL en un almacenamiento de vectores eficaz, permitiendo guardar embeddings junto con los datos transaccionales habituales. Es la opción natural para equipos ya comprometidos con Postgres que prefieren no crear otra base de datos.

Añade un tipo de columna de vectores nativo a los esquemas SQL convencionales, soporta la similitud coseno, la distancia L2 y el producto interno, crea índices HNSW e IVFFlat, y ejecuta consultas de similitud dentro de transacciones ACID estándar.

La gran ventaja es evitar la carga operativa, las revisiones de seguridad y el mantenimiento de un sistema separado. La supervisión, las copias de seguridad y la replicación existentes de Postgres se mantienen, y el filtrado de metadatos es simplemente una cláusula WHERE familiar junto con una función de distancia. Las desventajas son un mayor consumo de memoria y una escalabilidad menor en comparación con motores diseñados exclusivamente para vectores, además de un aumento notable de la latencia después de unos 50 millones de vectores, a menos que se añada algo como pgvectorscale.

La extensión es gratuita y de código abierto. Lo que tengas que invertir depende de cómo alojes Postgres.

Opciones pagadas y gestionadas

Las bases de datos gestionadas ofrecen una experiencia de bajo mantenimiento para que el equipo pueda centrarse en la aplicación en lugar de en los servidores.

Pinecone

Pinecone definió más o menos la categoría de bases de datos vectoriales gestionadas con un diseño sin servidores y sin operaciones, que oculta toda la infraestructura de backend. Está dirigido a equipos que desean llegar rápidamente a la producción sin tener que gestionar servidores, clústeres ni parámetros de índice.

Funciona exclusivamente como un SaaS en la nube, separa las capas de lectura, escritura y almacenamiento para que cada una se escale de forma independiente, alberga modelos de incrustación y reclasificación a través de Pinecone Inference, y admite vectores densos, vectores dispersos y un filtrado eficaz de metadatos. A cambio, no hay tareas de infraestructura, ni actualizaciones de parches ni reconstrucciones de índices, además de una amplia compatibilidad con frameworks y servicios en la nube, así como alta disponibilidad y un rendimiento predecible bajo carga.

Las desventajas son que es de código cerrado, lo que implica un verdadero encadenamiento al proveedor, y que la tarifa de consumo aumenta rápidamente en trabajos con muchas operaciones de lectura y escritura.

Los precios indicados son los siguientes: un nivel Starter gratuito (2 GB, 1 millón de lecturas, solo AWS us-east-1); Standard con un mínimo mensual de 50 dólares a 0,33 dólares por GB-mes, más aproximadamente de 4 a 4,50 dólares por millón de unidades de escritura y de 16 a 18 dólares por millón de unidades de lectura; Enterprise con un mínimo mensual de 500 dólares; y un complemento HIPAA por 190 dólares al mes.

Turbopuffer

Turbopuffer es un motor de búsqueda sin servidores desarrollado directamente sobre almacenamiento de objetos en la nube, y la eficiencia en los costos es su principal ventaja. Es la opción más adecuada para productos SaaS y de IA multiinquilinos con una gran cantidad de espacios de nombres, donde es necesario controlar los gastos.

Salta el disco convencional y busca directamente en el almacenamiento de objetos, maneja miles de millones de vectores sin límite en los nombres de espacio, utiliza un índice SPFresh optimizado para búsquedas y hace que las escrituras se muestren inmediatamente en los resultados. Los costos de almacenamiento y consultas disminuyen drásticamente en comparación con los servicios gestionados anteriores; se evitan las tarifas por pod que penalizan los diseños multiinquilinos, y la conformidad con SOC 2 e HIPAA está incluida en los planes estándar.

No obstante, es de código cerrado, tiene un historial más corto que sus rivales establecidos, y su ecosistema de complementos e integraciones es más limitado. La facturación se basa exclusivamente en el uso, con un mínimo mensual de 64 dólares en los planes estándar, y los nombres de espacio grandes reciben descuentos por volumen en las consultas.

TiDB Vector Search

PingCAP's TiDB Vector Search combina una base de datos SQL distribuida con su propio motor de incrustación, de modo que las grandes cargas de trabajo transaccionales y la recuperación semántica se ejecutan en un mismo sistema escalable. Es ideal cuando se necesita una escala horizontal muy amplia junto con filtrado SQL complejo y búsqueda vectorial en los mismos datos al mismo tiempo.

La plataforma integra almacenamiento de incrustaciones y SQL distribuido, crea índices SQL tradicionales junto a índices vectoriales HNSW, distribuye las consultas entre nodos para garantizar alta disponibilidad, y admite búsqueda híbrida y coincidencia exacta de palabras clave además de la similitud vectorial. Esto elimina los problemas de sincronización y los procesos intermedios entre una base de datos de aplicaciones y un almacén vectorial separado, permite búsquedas multiinquilino con filtrado intensivo a través de uniones SQL, y se escala sin ralentizar las consultas.

Es un exceso para un pipeline RAG ligero basado únicamente en vectores, y optimizar el rendimiento implica comprender en profundidad el SQL distribuido.

En TiDB Cloud Starter, la versión gratuita es la más generosa de la categoría: 5 GiB de almacenamiento de filas, 5 GiB de almacenamiento columnar y 50 millones de unidades de solicitud por clúster, con hasta 5 clústeres por organización. Eso suma 25 GiB para filas, 25 GiB para columnas y 250 millones de RUs al mes de forma gratuita. Más allá de eso, se cobra 0,10 dólares por millón de RUs y 0,20 dólares por GiB-mes para el almacenamiento de filas en us-east.

Dónde falla el RAG vectorial

La búsqueda vectorial es poderosa, pero aún presenta debilidades que afectan la precisión en su uso empresarial.

• Contexto perdido. El RAG vectorial estándar divide los documentos en fragmentos pequeños para adaptarse a las ventanas de contexto. Ese paso mecánico destruye la estructura de los documentos complejos, y un fragmento pequeño pierde fácilmente su conexión con los encabezados o secciones que le daban sentido.
• Imprecisión. La recuperación de información depende de la cercanía en el espacio vectorial, por lo que los términos similares o los nombres de productos con palabras en común se confunden. Hechos incorrectos terminan en la solicitud, lo que genera alucinaciones.
• Actualizaciones costosas. Pasar a un modelo de embedding mejor implica volver a generar embeddings para todo el corpus y reconstruir índices grandes desde cero, lo que aumenta los costos de procesamiento y los gastos.

Graph RAG es una alternativa. Modela los puntos de datos como nodos y las relaciones como aristas, y herramientas como el Writer Knowledge Graph mantienen enlaces explícitos entre documentos. Esto permite el razonamiento multi-paso, reduce las alucinaciones y permite a un equipo actualizar un único hecho sin tener que volver a incrustar todo.

Una forma práctica de decidir

Comience con lo que ya utiliza. En Postgres, con aproximadamente menos de 10 millones de vectores, pgvector maneja la tarea sin necesidad de nuevas dependencias, y pgvectorscale lo extiende a 50 millones o más. En MongoDB, utilice Atlas Vector Search. En Elastic o OpenSearch, puede seguir utilizando lo mismo, ya que OpenSearch 3.0 cerró la mayor parte de las brechas. En Redis, utilice el soporte nativo para vectores de Redis 8 con FT.HYBRID.

Si comienza desde cero, tenga en cuenta tres aspectos:

1. Capacidad de escala y operaciones. La creación de prototipos con menos de 1 millón de puntos vectoriales indica Chroma. La producción autohospedada con un rendimiento de filtrado excelente apunta a Qdrant. Los trabajos a escala de mil millones o acelerados por GPU sugieren Milvus. La producción gestionada con necesidades de cumplimiento normativo se orienta hacia Pinecone o Weaviate Cloud.
2. Forma del costo. En casos de distribución intensiva entre múltiples usuarios donde la mayoría permanece inactiva, los ahorros de 10 a 100 veces de Turbopuffer son reales, aunque las consultas “frías” tardan alrededor de 500 ms. Para configuraciones sensibles al costo con más de 50 millones de vectores y carga predecible, pgvector junto con pgvectorscale es la opción adecuada.
3. Requisitos de razonamiento. Para consultas de múltiples pasos, explicabilidad o estructura relacional, se debe añadir un grafo de conocimiento como Neo4j, Memgraph o FalkorDB y utilizar Graph RAG junto con los vectores, y no en su lugar.

Preguntas frecuentes

¿Cómo se construye una base de datos vectorial para RAG? Se dividen los documentos en fragmentos, se crean embeddings con un modelo como uno de OpenAI o BGE, y luego se almacenan e indexan los vectores en herramientas como Qdrant, Milvus o pgvector. Para una configuración completamente local, se utilizan Chroma o FAISS en una sola máquina, sin necesidad de la nube.

¿Qué papel desempeña? Es el motor de recuperación que se encuentra entre los documentos y el LLM. Almacena los embeddings y, en el momento de la consulta, devuelve los fragmentos más relevantes para que el modelo responda a partir de un contexto concreto y no solo de su memoria.

¿Qué base de datos debería usar? Depende de la escala y la tecnología utilizada. Chroma y pgvector son las mejores opciones gratuitas para proyectos de tamaño pequeño a medio, Qdrant y Milvus son los líderes para entornos de producción autohospedados, y Pinecone es la mejor opción gestionada cuando se desea cero mantenimiento.

¿Cómo se utilizan los vectores en el proceso? Un modelo de embedding convierte los fragmentos de texto en vectores de alta dimensión. La base de datos los almacena, y cuando llega una pregunta, encuentra los vectores más cercanos al vector de la consulta mediante búsquedas ANN y pasa esos fragmentos al prompt.

¿Es siempre necesaria una base de datos de vectores? No, aunque sigue siendo la opción predeterminada en la industria. Los sistemas sin vectores, como PageIndex, omiten por completo los embeddings. Convierten los documentos en árboles jerárquicos y permiten que el LLM razone a partir del índice de contenidos para encontrar respuestas. Muchos equipos empresariales también utilizan bases de datos de grafos para GraphRAG, recuperando contexto a través de conexiones explícitas en lugar de similitud espacial.

¿Cuáles son los siete tipos de RAG? RAG ingenuo (búsqueda básica seguida de generación), recuperación y reclasificación (el enfoque habitual en producción), RAG híbrido (búsqueda densa y dispersa combinadas), RAG multimodal (texto, imágenes y audio en un mismo proceso), RAG basado en grafos (navegación por grafos de conocimiento para consultas relacionales), RAG agente (un agente de LLM elige la mejor estrategia de recuperación para cada consulta) y RAG HyDE (el modelo redacta primero una respuesta hipotética y luego realiza búsquedas basadas en ella).