Si has leído sobre RAG, búsqueda con IA o recomendaciones, seguramente te has topado con el término base de datos vectorial. Aquí va la versión clara. Una base de datos vectorial guarda los datos como vectores -listas de números que capturan el significado- y encuentra elementos por similitud, no por coincidencia exacta. Esa única idea es lo que hace que la búsqueda con IA moderna parezca que te entiende.
Qué es realmente una base de datos vectorial
Las bases de datos normales son muy buenas con preguntas exactas: encontrar al usuario con este ID, o todos los pedidos de la semana pasada. Tienen problemas con «búscame cosas que signifiquen lo mismo». Una base de datos vectorial está hecha justo para eso.
Funciona con embeddings: las huellas numéricas que un modelo de IA da al texto, las imágenes o el audio. Los elementos con un significado parecido obtienen vectores que quedan cerca unos de otros. La base de datos guarda esos vectores y, cuando buscas, devuelve los más cercanos a tu consulta.
Cómo funciona la búsqueda por similitud
El flujo tiene tres pasos:
- Convertir en vector. Un modelo de embeddings convierte cada documento, imagen o frase en un vector.
- Indexar. La base de datos guarda esos vectores en un índice especial (como HNSW o IVF) para poder buscar rápido en conjuntos enormes.
- Consultar. Tu búsqueda también se convierte en vector. La base de datos devuelve los vectores más cercanos a ella por distancia.
Así, una búsqueda de «cómo restablecer mi contraseña» puede sacar a la luz un artículo llamado «recuperar un inicio de sesión olvidado». Las palabras son distintas, pero el significado -y los vectores- están cerca.
Base de datos vectorial frente a base de datos normal
Resuelven problemas distintos, y la mayoría de las apps reales usan ambas. Una base de datos relacional guarda tus registros estructurados y responde consultas exactas. Una base de datos vectorial responde «¿qué se parece más a esto?». Guardas las filas de clientes en una y el significado buscable en la otra. Herramientas como pgvector incluso te permiten añadir búsqueda vectorial a una base de datos PostgreSQL normal, así ambas viven en un mismo lugar.
Por qué importa para la IA
Una base de datos vectorial es el motor de recuperación detrás de buena parte de la IA. Impulsa la búsqueda semántica, las recomendaciones de productos y contenidos y -lo más importante- el paso de recuperación en el RAG, donde un asistente busca el texto relevante antes de responder. Sin una búsqueda por similitud rápida sobre embeddings, ninguna de esas funciones sería práctica a gran escala.
Cómo se mantiene rápida la búsqueda: el vecino más cercano aproximado
Comparar el vector de tu consulta con cada uno de los vectores guardados -una búsqueda del vecino más cercano exacta- es preciso pero lento en cuanto tienes millones de elementos. Por eso las bases de datos vectoriales se apoyan en algoritmos de vecino más cercano aproximado (ANN). El ANN intercambia un poquito de precisión por una enorme ganancia de velocidad: en lugar de revisar cada vector, recorre una estructura de índice inteligente que le da casi las coincidencias más cercanas, rápido.
Dos familias de índices hacen la mayor parte del trabajo:
- HNSW (Hierarchical Navigable Small World) construye un grafo por capas que puedes recorrer a saltos rápidamente. Es la opción por defecto más común: buen recall, baja latencia, más memoria.
- IVF (Inverted File) agrupa los vectores en cubetas y solo busca en las más cercanas. Escala a conjuntos muy grandes y usa menos memoria, a menudo junto con compresión (PQ) para reducir el tamaño de los vectores.
El ajuste que controlas es recall frente a latencia: pide más recall (más de los verdaderos vecinos más cercanos) y la búsqueda trabaja más. La distancia se mide con una métrica -normalmente similitud del coseno (el ángulo entre vectores), producto escalar o distancia euclídea (L2)- y el modelo de embeddings que uses suele determinar cuál es la correcta.
Bases de datos vectoriales comunes - y cuál elegir
No hay una única opción «mejor»; la elección correcta depende de la escala, de si quieres un servicio gestionado o autohospedarlo, y de si necesitas los vectores junto a datos relacionales existentes. Las opciones más usadas en 2026:
| Base de datos | Modelo | Buena opción cuando… |
|---|---|---|
| pgvector | Extensión de PostgreSQL | Ya usas Postgres y quieres los vectores junto a tus datos normales: una sola base de datos, sin servicio extra. |
| Chroma | Open source, integrable | Prototipos o una app pequeña; rápida de arrancar en local. |
| Qdrant | Open source, autohospedado o gestionado | Quieres un filtrado rico por metadatos y buen rendimiento manteniendo el control del hospedaje. |
| Weaviate | Open source, autohospedado o gestionado | Quieres módulos integrados (búsqueda híbrida, vectorización) y un enfoque basado en esquema. |
| Milvus | Open source, pensado para escalar | Colecciones muy grandes (cientos de millones o más) y cargas de alto rendimiento. |
| Pinecone | Totalmente gestionado (propietario) | Quieres un servicio serverless sin complicaciones y prefieres no administrar infraestructura. |
Una regla sencilla: empieza con pgvector si ya usas PostgreSQL, o Chroma para un prototipo rápido; pasa a Qdrant, Weaviate o Milvus cuando necesites escala, filtrado o control del autohospedaje; elige Pinecone cuando quieras un servicio gestionado sin operaciones. La mayoría de los equipos también usa búsqueda híbrida -combinando la similitud vectorial con la búsqueda por palabras clave tradicional- para obtener lo mejor de ambas.
En resumen
Una base de datos vectorial guarda el significado como vectores y encuentra elementos por similitud en lugar de por coincidencia exacta. No reemplaza tu base de datos normal: se coloca a su lado y responde las preguntas que una búsqueda por palabras clave nunca pudo. Si estás construyendo algo con búsqueda semántica o RAG, una base de datos vectorial es la pieza que hace el trabajo pesado.
Guías relacionadas: ¿Qué es la ingeniería de prompts? Mejores respuestas de la IA (2026).
