Precio de una base de datos vectorial: qué paga realmente

El precio de una base de datos vectorial no se reduce a una tarifa. Lo que realmente paga es memoria y almacenamiento (según cuántos vectores guarda y cuántas dimensiones tiene cada uno), cómputo para consultas e indexación, y tantas copias como réplicas mantenga. A eso se suman costes que no figuran en la factura: generar los embeddings, reindexar todo el corpus cada vez que cambia de modelo y las horas de ingeniería. Este artículo desglosa cada partida, enseña a estimar la memoria con aritmética básica y le ayuda a decidir si le hace falta una base vectorial.

Qué guarda en realidad una base vectorial

Una base vectorial almacena embeddings: listas de números que representan el significado de un fragmento de texto. Cada documento se divide en fragmentos (chunks) y cada fragmento recibe su propio vector. Cuando alguien pregunta, la pregunta también se convierte en vector y se buscan los fragmentos más cercanos. Si quiere ver ese recorrido completo con un ejemplo, consulte Cómo funciona RAG paso a paso.

La primera lección para el presupuesto: no paga por documento, sino por vector. Un PDF de 50 páginas puede dar 50 vectores o 500 según el tamaño de los fragmentos y su solapamiento. Esa decisión, que muchos equipos toman una vez y olvidan, puede multiplicar la factura por diez.

Las cuatro palancas del coste

Tanto si aloja un motor de código abierto como si añade una extensión a PostgreSQL o contrata un servicio gestionado, debajo hay los mismos recursos físicos. Los proveedores los facturan de forma distinta (por hora, por gigabyte, por unidad de lectura), pero las palancas son siempre estas cuatro.

1. Número de vectores

Cuente fragmentos, no archivos, y prevea el crecimiento: si su fondo documental se duplica en un año, el índice también.

2. Dimensiones y precisión

El modelo de embeddings fija las dimensiones; 384, 768, 1.024, 1.536 y 3.072 son tamaños habituales. En float32, cada dimensión ocupa 4 bytes, de modo que un vector de 1.536 dimensiones pesa unos 6 KB antes de contar el índice.

3. Volumen de consultas y latencia

Los índices de vecinos más cercanos aproximados, como los grafos HNSW descritos en el artículo original, son rápidos porque recorren un grafo en lugar de compararlo todo. Para mantener esa velocidad, el grafo suele tener que estar en memoria RAM. Más consultas por segundo, latencias más exigentes y filtros por metadatos piden más RAM y CPU.

4. Réplicas, entornos y clientes

En producción se suelen usar dos o tres réplicas, cada una con el índice completo. Si añade un entorno de pruebas y quizá un índice por cliente para separar datos, pagará los mismos vectores varias veces.

Cómo estimar el coste de almacenamiento de los embeddings

No necesita ninguna tarifa para estimar la memoria. La fórmula es: número de vectores × dimensiones × 4 bytes (en float32). Estas cifras son tamaños brutos, sin índice, metadatos ni réplicas.

Ejemplo: 1.000.000 × 1.536 × 4 = 6.144.000.000 bytes, es decir, unos 6,1 GB. Es solo el punto de partida. El índice en grafo guarda enlaces a los vecinos de cada vector, normalmente se conserva también el texto de los fragmentos y sus metadatos, y todo se multiplica por el número de réplicas. Un corpus que parecía caber en 6 GB acaba pidiendo varias decenas de gigabytes de RAM en el clúster.

Los costes ocultos: embeddings, reindexación y personas

• Generar embeddings. Cada fragmento pasa por un modelo de embeddings al importarlo, y cada pregunta se vectoriza al buscar. Tanto si llama a una API como si usa sus propias GPU, es un coste recurrente.
• Reindexar al cambiar de modelo. Los vectores de dos modelos distintos no son comparables. Cambiar de modelo, o de dimensión, obliga a recalcular y reconstruir todo el índice, a menudo con el antiguo aún en servicio.
• Volver a fragmentar. Si las respuestas son flojas y cambia la estrategia de fragmentación, toca vectorizar de nuevo todo el corpus. En los primeros meses ocurre más de una vez.
• Actualizaciones y borrados. Mantener los vectores sincronizados con los documentos exige un proceso, y algunos índices se degradan tras muchos borrados hasta que se reconstruyen.
• Copias de seguridad y transferencias. Instantáneas y copias entre regiones suman almacenamiento y salida de datos.
• Operación. Ajuste de parámetros, control de calidad, actualizaciones y guardias necesitan un responsable.

También cuenta el cumplimiento normativo. Con el RGPD, los embeddings calculados a partir de textos con datos personales, y guardados junto a esos textos, deben tratarse como datos personales: control de accesos, plazos de conservación, registro de actividades de tratamiento y ubicación del alojamiento. La AEPD publica orientaciones útiles, y el AI Act añade obligaciones propias según el uso que se haga del sistema.

Cuándo no necesita una base de datos vectorial

• Su corpus es pequeño. Unos miles de fragmentos caben sin problema en memoria y una comparación exhaustiva es lo bastante rápida.
• Las preguntas buscan términos exactos. Artículos de una ley, referencias de producto, códigos de error o nombres propios suelen encontrarse mejor con búsqueda de texto completo. La búsqueda híbrida, que combina palabras clave y significado, supera a menudo a los vectores solos.
• Ya usa PostgreSQL. Una extensión vectorial mantiene los embeddings junto a sus datos relacionales, con una sola política de copias y permisos.
• Quiere respuestas, no infraestructura. Si el objetivo es que su equipo o sus asistentes de IA consulten documentos, un servicio gestionado le ahorra la base, el proceso de embeddings y la reindexación.

En este último caso encaja Kopik, una plataforma de RAG como servicio. Crear una base es gratis: sube archivos PDF, Word, texto o Markdown, y Kopik los extrae, fragmenta e indexa para una búsqueda híbrida (texto completo más ampliación semántica de las palabras clave). No hay clúster que dimensionar ni dimensiones que elegir: las preguntas se pagan con créditos prepago o con la suscripción de chat a 12 € al mes con indicador de uso. Si su objetivo es que Claude consulte esos documentos, vea cómo dar acceso a Claude a los documentos de su empresa.

Lista de comprobación antes de comparar proveedores

1. Cuente los fragmentos actuales y estímelos a 12 meses.
2. Elija la dimensión de los embeddings y calcule vectores × dimensiones × 4 bytes.
3. Pruebe la cuantización con 50-100 preguntas reales.
4. Fije el número de réplicas y de entornos (producción, pruebas, por cliente).
5. Estime consultas diarias y el pico por segundo, contando los agentes de IA que buscan varias veces.
6. Presupueste embeddings para la carga inicial, las actualizaciones y al menos una reindexación completa al año.
7. Compruebe la ubicación de los datos (UE o no), el cifrado y los registros de auditoría de cada plan.
8. Ponga cifra al tiempo que su equipo dedicará a mantenerlo.