Lo que anunció AWS

El 5 de agosto de 2026, AWS anunció que Amazon DynamoDB ahora gestiona la búsqueda vectorial de forma nativa, sin necesidad de crear ni mantener un índice vectorial aparte. La empresa afirma que la función ofrece una latencia de milisegundos de un solo dígito con una precisión superior al 99 por ciento, y que escala hasta billones de vectores. SiliconANGLE e InfoWorld cubrieron el anuncio de forma independiente ese mismo día, describiéndolo como una capacidad nativa y no como un servicio añadido.

El mecanismo es sencillo: la búsqueda vectorial ahora se ejecuta en la misma tabla que ya almacena los datos principales de la aplicación. No hay una segunda base de datos que aprovisionar, ni un paso de exportación e importación, ni una canalización que tenga que mantener sincronizado un índice vectorial aparte con los cambios de la tabla de origen.

Ese último punto merece atención. Eliminar la canalización de sincronización elimina el retraso entre una actualización de un registro y su aparición en los resultados de búsqueda, y elimina toda una clase de errores que surge cuando dos almacenes de datos se desincronizan entre sí.

La categoría de proveedores que esto amenaza

Durante los últimos dos o tres años, añadir búsqueda semántica o generación aumentada por recuperación (RAG) a un producto ha significado casi siempre adoptar una segunda base de datos, construida específicamente para vectores, junto a la base de datos que ya guarda los datos reales. Pinecone, Weaviate y Milvus construyeron sus negocios exactamente sobre ese hueco, y las extensiones de Postgres cubrieron la misma necesidad para los equipos que querían quedarse con un solo motor.

Ese patrón se convirtió casi en una partida fija de los planes de proyectos de IA: presupuesto para un proveedor de bases de datos vectoriales, presupuesto de tiempo de ingeniería para una canalización de sincronización, y presupuesto para una segunda revisión de seguridad porque los datos de los usuarios ahora pasan por un segundo encargado del tratamiento. Ninguno de esos costes era exótico, pero todos se daban por necesarios.

Lo que AWS lanzó el 5 de agosto no borra esa categoría de proveedores, pero le quita la justificación automática en un caso grande y común: cualquier equipo cuyos datos principales de aplicación ya vivan en DynamoDB. Para ese grupo, el argumento a favor de una base de datos vectorial aparte ahora hay que volver a defenderlo, no darlo por supuesto.

Qué comprobar antes de aprobar tu próximo proyecto de IA

La instrucción práctica aquí es sencilla e inmediata. Antes de firmar un contrato con un proveedor de bases de datos vectoriales, y antes de asignar a un ingeniero para construir una canalización de sincronización de DynamoDB a una base de datos vectorial, alguien debería comprobar si DynamoDB ya puede hacer el trabajo por sí sola.

Esto importa sobre todo para los planes que ya estaban escritos. Cualquier plan de proyecto de IA redactado en los últimos dos años que incluya una línea de 'añadir una base de datos vectorial' se escribió bajo unas condiciones que AWS acaba de cambiar para los usuarios de DynamoDB. Reabrir ese plan cuesta una tarde; no reabrirlo cuesta un contrato con un proveedor y una canalización de mantenimiento que quizá no hiciera falta.

La comprobación en sí es limitada: si los datos principales de la aplicación ya viven en DynamoDB, y si la escala y la latencia requeridas encajan dentro de lo que AWS ha publicado. Si ambas respuestas son sí, la base de datos vectorial aparte pasa a ser opcional en lugar de darse por supuesta.

Dónde una base de datos vectorial aparte sigue teniendo sentido

Nada de esto significa que haya que retirar cualquier base de datos vectorial dedicada. Los equipos que operan a una escala extrema, o en varios proveedores de nube a la vez, pueden seguir teniendo razones que no tienen nada que ver con la nueva capacidad de DynamoDB.

Las arquitecturas ya construidas y estables alrededor de Pinecone, Weaviate o Milvus tampoco necesitan cambiar por la fuerza de un solo anuncio. Una migración tiene su propio coste, y un sistema que funciona y cumple sus requisitos no merece automáticamente que lo toquen.

La postura honesta es que esto es una nueva comprobación, no un mandato. Algunos equipos harán la comprobación y mantendrán su base de datos vectorial aparte porque tienen una razón auténtica para ello. El fallo no está en comprobar, sino en no comprobar en absoluto y quedarse con la vieja suposición por costumbre.

Qué vigilar a partir de ahora

La consecuencia más inmediata para los equipos de protección de datos de la UE y el Reino Unido es de cumplimiento: cualquier equipo que traslade su búsqueda vectorial a DynamoDB elimina un segundo encargado del tratamiento y un segundo acuerdo de protección de datos de su revisión de proveedores, porque los datos de los usuarios ya no tienen que pasar por un proveedor de bases de datos vectoriales aparte.

Vale la pena observar cómo reaccionan los proveedores dedicados de bases de datos vectoriales. Una capacidad así, lanzada por el proveedor que ya guarda una gran parte de los datos subyacentes, es el tipo de movimiento que suele obligar a la competencia a diferenciarse con claridad o a competir más fuerte en precio.

También vale la pena observar si otros grandes proveedores de bases de datos en la nube incorporan una capacidad vectorial similar a sus propias bases de datos principales en los próximos meses. Si el movimiento de AWS se repite en otros sitios, la suposición de que las funciones de IA necesitan una base de datos aparte quedará anticuada mucho más allá de DynamoDB.

Leer a continuación: La cartera eran 1.500 millones. El bono también.  |  El dinero de la escasez salió como recompra