Bases de datos vectoriales sin jerga

¿Qué hace un índice vectorial?

El embedding convierte cada chunk de texto en una fila de números — normalmente 768, 1.024 o 1.536 números. La búsqueda a partir de ahí es geometría: qué fila de números está más cerca de la de tu pregunta. Ese paso lo explica con más detalle el texto sobre embeddings y búsqueda vectorial desde la base.

El problema en una frase: si tienes un millón de chunks, habría que calcular un millón de distancias en cada pregunta. El índice vectorial existe para que no haga falta.

Existen tres planteamientos, y conviene saber qué sacrifica cada uno:

La solución basada en grafo es la más extendida, y con la analogía de sus propios autores es fácil de entender: es como un mapa de varias plantas. En la planta más alta hay pocos puntos y saltos largos; según bajas, hay más puntos y pasos más cortos. La búsqueda empieza arriba, da saltos grandes y luego se acerca cada vez más fino.

Lo que hay que llevarse de aquí: todos son aproximaciones, menos el primero. La búsqueda vectorial no garantiza que dé el mejor resultado — solo que da muy rápido un resultado muy bueno. Normalmente basta, pero no siempre; eso es de lo que trata el artículo sobre hybrid search con sus cifras.

El cálculo de memoria que decide la cuestión

Aquí está la tabla más importante del artículo. [Cálculo propio] a partir de la fórmula oficial de planificación de capacidad del fabricante, con vectores de 1.536 dimensiones:

vector / chunk = 1.536 dimensiones × 4 bytes = 6.144 bytes ≈ 6 KB
índice / chunk = 16 × 2 × 4 bytes × 1,2      = 154 bytes

De esa sola tabla se leen los umbrales de dolor:

• 10 mil vectores: 75 MB. Caben en cualquier sitio. No hace falta nada especial.
• 1 millón de vectores: 7,5 GB. Ya no caben en una máquina virtual pequeña, sí en un servidor normal. Aquí empieza a contar la quantization.
• 10 millones: 75 GB. Aquí la memoria pasa a ser la partida principal, y aquí empieza a tener sentido el índice en disco.
• 100 millones: 755 GB. Mantenerlo en memoria por un dinero razonable ya no es una vía practicable.

Y fíjate en la columna del índice: en este ejemplo es en todas partes el 2-3 % del tamaño total — en el ejemplo propio del fabricante, de 768 dimensiones, es el 5 %. El mito de que «el índice vectorial es caro» viene de confundir el índice con los vectores.

Dos multiplicadores que más a menudo se quedan fuera de la planificación: la replicación duplica la memoria, y el número de dimensiones la multiplica linealmente. Este último es el más potente que puedes ajustar libremente — pasar de 1.536 a 512 dimensiones deja la memoria en un tercio.

Con la quantization baja todavía más: a la mitad con media precisión, a una cuarta parte con quantization de ocho bits — con una pérdida de precisión prácticamente nula, según la medición del fabricante. Del tema se ocupa a fondo el artículo sobre quantization y sus compromisos.

¿Hace falta de verdad una base de datos aparte?

Esta es la pregunta real del lector desarrollador, y en 2026 la respuesta ha cambiado.

Hay elección precisamente porque la búsqueda vectorial no es un tipo de base de datos, sino una capacidad. La misma base de datos relacional que ya guarda los datos reales de la empresa puede aprenderla: Postgres tiene una extensión llamada pgvector que le añade un tipo de columna vectorial y los índices de proximidad correspondientes. Así el fragmento de texto y su embedding quedan uno al lado del otro en la misma tabla, y la búsqueda es SQL normal — en la misma consulta que el filtro de metadatos.

Y pgvector se ha puesto al día. La versión de julio de 2026 sabe hacer índices de grafo y de clústeres, quantization de ocho bits y binaria, media precisión — y desde finales de 2024 sabe también lo que era la queja más antigua contra ella: la búsqueda combinada con filtrado, donde antes volvían demasiados pocos resultados.

Conviene saber de antemano una limitación importante: el tipo vectorial básico indexa como mucho 2.000 dimensiones. Los modelos de embedding grandes hoy habituales dan 3.072 dimensiones — eso no cabe. Hay dos salidas: el tipo de media precisión (hasta 4.000) o reducir el número de dimensiones del embedding, cosa que los modelos grandes admiten.

NO NECESITAS UNA VECTOR DATABASE APARTE SI

- tu Postgres ya está ahí y los vectores caben;
- el tamaño aún no justifica el índice (hasta unos
  cientos de miles, la búsqueda exacta suele bastar);
- el filtrado por metadatos es la operación principal:
  filtro relacional más un conjunto pequeño es simple.

SÍ LA NECESITAS SI

- la memoria necesaria supera la de tu máquina y el
  almacenamiento en disco o por capas es la única vía;
- las consultas por segundo son el criterio principal;
- necesitas hybrid search nativo, en un solo índice.

Las transacciones y los JOIN son algo que una base de datos relacional sabe hacer y una vector database no — y ese criterio falta en casi todas las comparativas.

¿Qué dice la medición?

Hay una comparativa pública de siete sistemas con el mismo presupuesto mensual, sobre un millón de vectores. Cuatro filas de ella:

Hay dos cosas que leer. Una: con el mismo presupuesto hay una diferencia de orden de magnitud en capacidad de consulta — de 1.147 a 13.316.

La otra es la más importante: el sistema más rápido no da los mejores resultados. El sistema C trabaja con el triple de latencia, pero logra el recall más alto. Si lo que cuenta es encontrar la respuesta correcta — y en RAG eso es justo lo que cuenta —, el ganador del benchmark no es necesariamente tu ganador.

(La medición la hizo uno de los participantes, con su propio framework de código abierto, y gana su propio producto. El código es abierto y hay una variante independiente. La fecha de la medición no aparece en la página — eso ya es una reserva.)

Lo que de ahí NO se puede afirmar: cuántas veces más lento es pgvector frente a los sistemas dedicados. No he encontrado una medición independiente de 2026 sobre eso — la extensión ni siquiera aparece en la comparativa citada.

Cuatro lógicas de precios que no se pueden comparar

Esta es la parte más práctica del artículo, porque las listas de precios de los proveedores no son comparables:

Y la consecuencia práctica que casi todos los cálculos se dejan: el mínimo mensual de los planes de entrada va de 16 a 250 dólares. Una base de conocimiento de diez mil documentos consume una fracción de eso. La cuota mínima es tu coste real, no el consumo — es decir, un sistema pequeño sale desproporcionadamente caro.

El mercado en 2026: qué vive y qué ha desaparecido

Este capítulo está aquí porque este sector cambia más deprisa que ningún otro, y escribir de memoria sobre él es equivocarse garantizado.

Ha desaparecido como producto propio: a uno de los primeros participantes lo compró en junio de 2024 un gran desarrollador de modelos, y los usuarios existentes tuvieron 90 días para pasarse a otra solución.

Un cambio de nombre que es una trampa: la empresa que desarrolla una base de datos de series temporales cambió de nombre en junio de 2025 — pero sus extensiones no. Quien escriba de memoria usará el nombre antiguo de la empresa o renombrará también la extensión. Las dos cosas están mal.

Comprados, pero siguen vivos: dos conocidos desarrolladores de embedding y re-ranking también cambiaron de manos, en febrero y en octubre de 2025. Los modelos siguieron disponibles.

Y el buque insignia de la categoría, en apuros: cambió de director en septiembre de 2025 y, según la prensa, se plantea una venta. (Esto es [información de prensa], no un anuncio de la empresa. El producto funciona en septiembre de 2026, está disponible y tiene lista de precios — eso lo he comprobado.)

El cuadro más amplio que lo explica: los actores ya establecidos — las bases de datos relacionales, los motores de búsqueda, las plataformas cloud — han añadido todos la búsqueda vectorial. Con eso han quitado el argumento principal para meter una base de datos entera nueva.

Latencia: dos cifras del mismo sistema

Datos propios de un proveedor, sobre los mismos diez millones de documentos:

Sesenta veces de diferencia, dentro del mismo sistema. Muestra bien que una arquitectura no es igual de barata para cada tipo de operación — y que si planeas hybrid search, el lado del texto puede ser tu cuello de botella.

La guía práctica

1. CALCULA EL TAMAÑO ANTES DE ELEGIR
   chunks × dimensiones × 4 bytes. Si el resultado
   baja de un gigabyte, no lo compliques.

2. MIRA QUÉ TIENES YA
   Si tienes Postgres, probablemente lo resuelve.
   Una base de datos menos, transacciones de más.

3. COMPRUEBA EL LÍMITE DE DIMENSIONES
   Las 3072 dimensiones de los modelos grandes no
   caben indexadas en el tipo vectorial básico.

4. LAS DIMENSIONES SON EL MULTIPLICADOR MÁS FUERTE
   De 1536 a 512: la memoria cae a un tercio.
   Prueba esto antes de cambiar de arquitectura.

5. PRIMERO QUANTIZATION, LUEGO MÁQUINA MAYOR
   La quantization de ocho bits deja la memoria en
   un cuarto, con pérdida apenas medible.

6. NO ELIJAS EL MÁS RÁPIDO, SINO EL MÁS PRECISO
   En la medición el sistema más rápido no dio los
   mejores resultados. En RAG cuenta el resultado.

7. MIRA EL MÍNIMO MENSUAL, NO EL PRECIO UNITARIO
   Con una base pequeña, el mínimo es todo el coste.

8. LO QUE ELIJAS HOY NO DEBE SER IRREVERSIBLE
   En dos años este sector ha visto un cierre, un
   cambio de nombre, tres compras y un relevo.

El octavo punto no es exceso de prudencia en esta categoría. Guarda también en tu propio almacenamiento los chunks en bruto y los metadatos: el embedding lo puedes volver a calcular cuando quieras, pero tus documentos no los recuperas de un servicio cerrado.

Malentendidos habituales

• «El índice vectorial se come mucha memoria.» Según la fórmula oficial, el grafo es un pequeño porcentaje de la memoria total. Los que se la comen son los vectores.
• «La búsqueda vectorial encuentra el mejor resultado.» Solo la búsqueda exacta lo garantiza. Los índices rápidos son todos aproximados.
• «Necesito una vector database si monto un RAG.» Hasta unos cientos de miles, tu base de datos actual suele bastar. Esto es una herramienta de escalado, no un requisito de entrada.
• «El ganador del benchmark es la mejor opción.» En la misma medición el sistema más rápido dio menos recall que uno con el triple de latencia.
• «El almacenamiento es el coste principal.» El almacenamiento es calderilla. La cuota mínima y el coste de modelo de responder son la partida real.
• «Esto lo decido una vez y ya está.» En dos años este sector ha visto un cierre, un cambio de nombre de empresa y varias compras. Planifica una vía de salida.

Qué llevarte

La matemática de la búsqueda vectorial es más simple que su marketing. Lo que hay que saber: la memoria crece con los vectores, no con el índice, el número de dimensiones es tu palanca más fuerte y hasta unos cientos de miles muchas veces no hace falta nada especial.

Antes de elegir merece la pena calcular una sola línea: número de chunks × dimensiones × 4 bytes. Si el resultado baja de un gigabyte — y con diez mil documentos suele bajar —, la pregunta no es qué vector database elegir, sino si hace falta alguna.

Y una cosa que importa más que la elección tecnológica: guarda tus textos en bruto. El embedding se puede recalcular; una base de conocimiento rescatada de un servicio cerrado, no. Por qué y cómo trocear lo cuenta el post sobre chunking desde el principio, y para el cuadro completo está el artículo pilar sobre RAG explicado en su conjunto.