Elegir base de datos vectorial: escala, filtrado, híbrido y coste

Primera entrega del bloque quinto, dedicado a la plataforma. El catálogo de bases de datos vectoriales tiene ya varias decenas de nombres y casi todos prometen lo mismo. Aquí van los cuatro criterios que dejan la lista en dos o tres candidatos reales en diez minutos, y un quinto que decide más de lo que nadie admite.

Recordemos en una frase qué hace esta pieza. Una base de datos vectorial almacena los vectores que representan el significado de cada fragmento del corpus y responde a una pregunta muy concreta: dado este vector de consulta, devuélveme los k más parecidos. Lo hace con índices aproximados —HNSW, IVF y familia, que vimos en la entrega 05— porque comparar contra todos los vectores uno a uno deja de ser viable enseguida.

El problema de elegir no es técnico en el sentido habitual: casi todas las opciones funcionan. La diferencia está en dónde te dejan atrapado cuando el proyecto crece y en cuánto trabajo operativo reclaman cada semana. Por eso los criterios que siguen no van de rendimiento bruto: van de encaje.

Criterio 1: cuántos vectores, ahora y dentro de un año

Es el primer filtro y el que más gente calcula mal, porque se estima sobre documentos en lugar de sobre fragmentos. Un manual de cuatrocientas páginas troceado en fragmentos de quinientos tokens no es un vector: son varios miles. La cuenta correcta es documentos por fragmentos medios por documento, y si indexas más de una representación —hijo y padre, o varias ventanas— hay que multiplicar otra vez.

Con ese número en la mano, los tramos son bastante nítidos:

• Hasta unos cientos de miles de vectores. Cabe cómodamente en casi cualquier cosa, incluido PostgreSQL con pgvector y las opciones embebidas. El índice entra en memoria en una máquina modesta. La elección se decide por otros criterios, no por escala.
• Del orden de millones. Sigue siendo territorio de PostgreSQL si el resto acompaña, pero ya hay que pensar en memoria del índice, tiempos de construcción y ventanas de reindexación.
• Decenas de millones y más. Aquí se necesita reparto en fragmentos (sharding), replicación, cuantización para que el índice quepa y una operativa pensada. Es el terreno natural de los motores dedicados y de los servicios gestionados.

El crecimiento previsto importa tanto como el volumen actual. Un corpus estático de dos millones de vectores y uno que crece cien mil al mes son problemas distintos: el segundo obliga a pensar en indexación incremental, borrados y coste de mantenimiento del índice, que es lo que vimos en la entrega 13.

Criterio 2: el filtrado por metadatos, y si es previo o posterior

Este es el criterio que más proyectos rompe en producción, y casi nunca aparece en las comparativas de marketing.

Casi ningún RAG real busca sobre el corpus entero. Busca sobre los documentos de este cliente, de esta unidad de negocio, publicados después de tal fecha, con este nivel de confidencialidad. Ese filtro no es un adorno: en muchos casos es un requisito de seguridad, como veremos en la entrega 45. Hay tres maneras de implementarlo y sólo una es buena.

Filtrado posterior. El motor busca los k vecinos más próximos en todo el índice y después descarta los que no cumplen el filtro. Falla de forma silenciosa: si el filtro es selectivo puedes pedir diez resultados y quedarte con uno o con ninguno, sin error, con menos contexto del debido y con un «no encuentro información sobre eso» falso.

Filtrado previo con escaneo. Se aplica primero el filtro y después se busca por fuerza bruta dentro del subconjunto. Es exacto, y es lento cuando el subconjunto sigue siendo grande.

Filtrado integrado en el recorrido del índice. El motor evalúa el filtro mientras navega el grafo o las celdas del índice aproximado, de modo que sólo considera candidatos válidos sin abandonar la estructura. Es la implementación correcta y es la que separa a los motores serios del resto. Pregunta explícitamente por ella; el término que suelen usar es filtered vector search o filtrado nativo.

Además del cómo, mira el qué: qué tipos de dato admite el filtro, si permite rangos y si permite operadores de pertenencia sobre listas, imprescindibles para permisos de tipo «este documento es visible para estos cinco grupos».

Criterio 3: búsqueda híbrida nativa o cosida a mano

En la entrega 15 vimos por qué la búsqueda densa sola no basta: falla justo donde el usuario escribe un código de producto, una referencia normativa, un número de artículo o un nombre propio poco frecuente. La combinación de búsqueda vectorial y búsqueda léxica tipo BM25, fusionadas por rango recíproco, es hoy la línea base razonable de cualquier sistema serio.

La pregunta para el motor es si eso viene de fábrica. Las opciones, de mejor a peor:

• Híbrido nativo con fusión incorporada. Una consulta, un viaje de red, el motor mantiene coherentes los dos índices y fusiona internamente.
• Los dos índices en el mismo motor, fusión en tu código. Aceptable: la fusión la mantienes tú, pero los datos no se duplican.
• Dos sistemas separados. Un motor vectorial y un buscador léxico aparte. Funciona, y compra dos problemas: sincronizar dos índices sobre el mismo corpus y duplicar la lógica de borrado y actualización.

Un matiz que ahorra discusiones: si tu corpus es prosa narrativa sin códigos ni referencias, la búsqueda densa sola puede bastar. Si es documentación técnica, catálogo o normativa, vas a necesitar híbrido seguro.

Criterio 4: el coste total, con la operación dentro

El error clásico es comparar la factura mensual de un servicio gestionado con el precio de la máquina donde correría el motor autoalojado. Esa comparación siempre gana el autoalojado y siempre está mal.

El coste real tiene cuatro sumandos:

• Cómputo y memoria. Los índices HNSW viven en memoria: es el recurso que manda. La estimación gruesa es dimensiones por bytes por dimensión por número de vectores, más el sobrecoste del grafo, que no es despreciable. La cuantización cambia esta cuenta por completo, y por eso importa que el motor la soporte.
• Almacenamiento y tráfico. Baratos en comparación, con una excepción: en los gestionados, el coste de salida de datos aparece justo cuando quieres irte.
• Horas de persona. Actualizaciones, copias de seguridad, monitorización, respuesta a incidentes, reindexaciones. Es el sumando que nadie apunta y el que más suele pesar en equipos pequeños.

Puesto en una frase: un motor autoalojado sale más barato en factura y más caro en atención. Si ya tienes plataforma de contenedores, guardias y automatización, una pieza más apenas se nota. Si no la tienes, esa pieza es un proyecto.

El quinto criterio, el silencioso

Qué sabe ya operar tu equipo.

Es el criterio que decide de facto la mitad de las elecciones y el que menos se escribe en los documentos de decisión, porque suena poco técnico. No lo es. Una base de datos que tu equipo ya sabe respaldar, restaurar, monitorizar, actualizar y depurar a las tres de la mañana vale más que una teóricamente superior con la que nadie ha tenido nunca un incidente.

Si ya tienes PostgreSQL en producción con copias de seguridad probadas y alguien que sabe leer un plan de ejecución, pgvector parte con una ventaja enorme, y hace falta un argumento sólido de escala o de funcionalidad para justificar la alternativa. Si ya tienes Elasticsearch o MongoDB indexando tu contenido, su búsqueda vectorial merece una prueba seria antes de añadir un sistema.

La regla práctica: añade un sistema nuevo sólo cuando los cuatro criterios anteriores lo exijan, no cuando lo sugieran. Cada pieza de infraestructura nueva se paga en atención durante años.

Árbol de decisión

Recorrido en orden, con la respuesta más común primero:

• ¿Es un prototipo o una prueba de concepto que va a durar semanas? Usa una opción embebida —Chroma, LanceDB o Faiss— y no montes nada. Entrega 32.
• ¿Ya tienes PostgreSQL en producción y esperas menos de unos pocos millones de vectores? pgvector. Es la respuesta correcta en más casos de los que la industria admite. Entrega 29.
• ¿Ya tienes Elasticsearch, MongoDB o Redis con datos que van a formar parte del corpus? Prueba primero su capacidad vectorial. Evitar la sincronización entre dos sistemas vale mucho. Entrega 31.
• ¿Necesitas decenas de millones de vectores, filtrado complejo o cuantización, y tienes equipo de operaciones? Motor dedicado de código abierto: Qdrant, Weaviate o Milvus. Entrega 30.
• ¿Necesitas esa escala pero no tienes equipo de operaciones? Gestionado. Cuesta más en factura y menos en riesgo. Entrega 31.
• ¿Ninguna encaja limpiamente? Casi siempre significa que lo que te complica es el filtrado o la multitenencia, no la escala. Vuelve al criterio 2.

Límites de este ejercicio

Tres advertencias antes de cerrar.

La primera: elegir motor no mejora la calidad de las respuestas. Es una decisión de plataforma, no de recuperación. Ninguna base de datos vectorial arregla un troceado malo ni unos metadatos inexistentes. Si el sistema responde mal, este no es el sitio donde mirar.

La segunda: los benchmarks públicos sirven menos de lo que parece. Miden consultas por segundo y recall sobre conjuntos sintéticos, con configuraciones afinadas por quien publica y sin tu patrón de filtrado, que es justo lo que va a dominar tu latencia real. Úsalos para descartar disparates, no para decidir.

La tercera: la migración entre motores es incómoda pero no catastrófica, y conviene reducirla a un problema pequeño desde el principio. Si aíslas el acceso al índice detrás de una interfaz propia con cuatro operaciones —insertar, borrar, buscar, buscar con filtro— cambiar de motor es reescribir un archivo. Si esparces llamadas al cliente del proveedor por todo el código, es reescribir el proyecto.

Qué viene ahora

La siguiente entrega baja al primer candidato del árbol de decisión y lo examina a fondo: pgvector dentro de PostgreSQL. Tipos de vector, operadores de distancia, los dos índices disponibles y sus parámetros, el problema real del filtrado combinado con SQL sobre un índice aproximado, y hasta dónde llega antes de rendirse. Es una entrega de nivel avanzado y con SQL de verdad.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.