Bases de datos vectoriales: qué son y cuándo las necesitas

¿Qué es una base de datos vectorial?

Una base vectorial guarda embeddings en un espacio de muchas dimensiones y, dado un vector de consulta, devuelve los más cercanos. Una base tradicional, en cambio, localiza registros por coincidencia exacta: el usuario con este correo, los pedidos de esta fecha. Si todavía no tienes claro cómo se generan esos vectores, empieza por embeddings; para ver por qué buscar por significado cambia la experiencia, lee búsqueda semántica.

Para ser rápida, la base suele implementar algoritmos de búsqueda aproximada de vecinos más cercanos. La búsqueda exacta compara la consulta con todos los vectores, y su costo crece con el número de puntos y de dimensiones. La aproximada acepta devolver un resultado muy cercano al mejor, aunque no siempre el mejor, a cambio de velocidad y menos memoria.

Entre las técnicas habituales están los grafos HNSW, el hashing sensible a la localidad, la cuantización de producto y los archivos invertidos. HNSW, descrito por Malkov y Yashunin en 2016, organiza el índice como capas de grafos de proximidad: la búsqueda empieza en las capas superiores, con saltos largos, y baja hasta las capas densas. Sus autores reportan que supera a enfoques de código abierto anteriores basados solo en vectores y que escala de forma logarítmica.

¿Qué productos existen y en qué se diferencian?

Hay dos familias. Unas son bases creadas para vectores; otras son extensiones o funciones de una base que ya usas. Según su documentación oficial a noviembre de 2026:

No hay un ganador universal: cada una resuelve un punto distinto del espacio entre simplicidad y escala. Las cifras de rendimiento y precio cambian rápido y dependen de tus datos, así que no las uses para elegir: pruébalas con tu colección.

¿Por qué le importa a un diseñador?

Porque la base vectorial es el lugar donde se decide qué encuentra el usuario y qué recibe el modelo:

• Resultados “parecidos”. La búsqueda aproximada no garantiza el mejor resultado exacto. Eso puede explicar por qué un resultado relevante aparece en el puesto cuatro.
• Latencia. La búsqueda es rápida, pero se suma al tiempo de cada respuesta de un asistente con RAG. Muéstrala como paso visible si es larga.
• Filtros. Un usuario que busca “documentos de 2026 del equipo de marca” necesita combinar similitud con filtros exactos. La documentación de pgvector advierte que, con índices aproximados, el filtro se aplica después de recorrer el índice: con el valor por defecto de HNSW (ef_search de 40) y un filtro que cumple el 10 % de las filas, devolvería unas 4 filas en promedio en lugar de las que pediste. Qdrant, en cambio, describe que su índice de payload extiende el grafo HNSW para filtrar durante la búsqueda. La consecuencia de diseño es real: una pantalla de resultados puede quedar casi vacía por un filtro mal soportado.
• Permisos y clientes. Si varios clientes comparten una base, hay que separar sus datos. Pinecone usa namespaces para eso; en otras bases se resuelve con metadatos y filtros. Un fallo aquí muestra a un usuario documentos de otro.
• Actualización. Cuando cambia un documento, su embedding debe recalcularse. El usuario espera que una corrección aparezca rápido; diseña para eso.

¿Cuándo NO la necesitas?

Cuando la colección es pequeña. Unos cientos de documentos caben en memoria y se pueden comparar todos contra la consulta sin problema. Chroma, por ejemplo, permite arrancar en memoria en tu máquina, aunque sus propios documentos advierten que así los datos se pierden al cerrar el programa.

Tampoco hace falta una base dedicada si tu base relacional ya tiene una extensión vectorial y el volumen es moderado: agregar una tecnología nueva tiene costo operativo. Si tu equipo ya usa PostgreSQL, pgvector permite guardar los vectores en la misma fila que el resto de los datos. Para entender ese tipo de base, lee bases de datos para diseñadores.

Y si la consulta depende de identificadores o de reglas exactas, una base tradicional con índices sigue siendo la herramienta correcta.

¿Cómo decidir?

1. Cuenta tus vectores: cientos, miles, millones. El orden de magnitud cambia la respuesta.
2. Mide la latencia objetivo de tu función.
3. Define los filtros que necesitas, por fecha, usuario, idioma o permisos, y comprueba cómo los maneja el producto con índice aproximado.
4. Revisa qué ya usas: si tu base actual soporta vectores con filtros, empieza ahí.
5. Prueba la calidad con casos reales antes de comparar motores, porque la mejor base no corrige un embedding malo. Si construyes un asistente de respuestas, mira también cómo se recupera el contexto en RAG.

Ejemplo

Ejemplo ilustrativo: un estudio de diseño tiene 6.000 fragmentos de investigación de usuarios. El asistente interno busca por similitud y filtra por proyecto y fecha. Al principio, el equipo instala una base dedicada, pero el volumen es bajo y la complejidad de mantenerla no vale la pena. Migra a una extensión vectorial en la base que ya usaban para proyectos. Al probar un filtro muy restrictivo por proyecto, el listado devuelve pocos resultados: el diseñador lo detecta en las pruebas y pide a ingeniería revisar la configuración del filtro con el índice. El diseñador define la interfaz de filtros como parte del producto, no como un detalle técnico.

Errores comunes

• Instalar una base vectorial dedicada para una colección de cien documentos.
• Olvidar que la búsqueda aproximada puede omitir el mejor resultado exacto.
• No probar los filtros con índice aproximado y descubrir tarde que devuelven pocos resultados.
• Mezclar embeddings de modelos distintos en la misma colección.
• No planificar la reindexación cuando cambian los documentos o el modelo de embeddings.
• Diseñar filtros después de construir el índice, cuando debían guiar su estructura.

Fuentes

• Vector database, Wikipedia
• Nearest neighbor search, Wikipedia
• Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs (arXiv:1603.09320)
• pgvector: repositorio y documentación en GitHub
• Qdrant: documentación, visión general
• Pinecone: documentación, visión general
• Weaviate: documentación
• Chroma: primeros pasos