¿Porqué AWS lanzó otro almacén de vectores?

Este artículo fue traducido usando IA.

Cuando AWS anunció DynamoDB Vector Search la semana pasada, mi primer pensamiento fue… ¿no acaba AWS de lanzar S3 Vectors?

Es decir, S3 Vectors se lanzó en disponibilidad general en diciembre. Ha pasado menos de un año, y ahora tenemos otro servicio que almacena vectores y hace búsqueda por similitud. Siendo honesto, estaba un poco confundido. Así que decidí investigar y entender qué está pasando.

El panorama de vectores en AWS

Antes de hablar específicamente de DynamoDB Vector Search, reconozcamos el elefante en la habitación. AWS ya tiene capacidades de vectores en muchos lugares:

• Amazon OpenSearch
• Aurora PostgreSQL
• Amazon DocumentDB
• Amazon MemoryDB
• Amazon Neptune
• Amazon S3 Vectors
• Amazon DynamoDB Vector Search

¡Son siete servicios! Mientras los listaba, la pregunta se hacía aún más fuerte en mi cabeza: ¿por qué AWS nos está dando otro más?

Mi pensamiento inicial

Mi primer instinto fue comparar DynamoDB Vector Search y S3 Vectors directamente. Ambos almacenan vectores, realizan búsqueda por similitud, soportan cargas de trabajo de IA y son serverless. En papel, suenan como lo mismo.

Empecé a revisar la documentación de ambos servicios tratando de descifrar cuál era “mejor.” Estaba viendo las dimensiones soportadas, funciones de distancia, límites de consultas, lo típico de una comparación.

Y entonces me di cuenta de que estaba haciendo la pregunta equivocada. La pregunta no es ¿cuál vector store es mejor?, la pregunta es: ¿qué tipo de datos representan estos vectores?

Esa distinción lo cambia todo, no se trata de los vectores en sí, sino de a qué están asociados.

Vectores operacionales

Piensa en los datos que viven en la ruta crítica de tu aplicación:

• Usuarios: embeddings de perfil para personalización
• Productos: embeddings del catálogo para recomendaciones
• Memoria de sesión: contexto de conversación para agentes de IA
• Recomendaciones: sugerencias en tiempo real basadas en comportamiento
• Detección de fraude: coincidencia de patrones en transacciones

Todos estos son operacionales, son datos que cambian frecuentemente, se consultan con requisitos de baja latencia, viven junto a otros datos de la aplicación que tu código ya lee y escribe, y son el estado de tu aplicación.

Aquí es donde DynamoDB Vector Search tiene sentido. Si tu catálogo de productos ya vive en DynamoDB, ¿por qué copiarías esos embeddings a una base de datos de vectores separada? Tendrías que construir un pipeline de sincronización, manejar consistencia eventual, administrar otro servicio y pagar por el movimiento de datos. Con búsqueda vectorial nativa, almacenas el embedding junto al item y lo consultas en el mismo lugar con una sola escritura dentro del mismo servicio.

Vectores de conocimiento

Ahora piensa en una categoría diferente de datos:

• PDFs: documentos empresariales, artículos de investigación
• Documentación: wikis internas, manuales de producto
• Políticas: documentos de cumplimiento, manuales de recursos humanos
• Artículos de soporte: contenido de base de conocimientos
• Código: embeddings de repositorios para búsqueda

Estos son activos de conocimiento, no cambian con mucha frecuencia, típicamente son colecciones grandes que se ingestan en lote, y alimentan pipelines de RAG donde una IA recupera contexto antes de generar una respuesta. No pertenecen a la base de datos transaccional de tu aplicación porque se usan como material de referencia en lugar del estado de la aplicación.

Aquí es donde S3 Vectors brilla. Está diseñado específicamente para almacenar colecciones masivas de embeddings al menor costo posible. Está optimizado para el patrón donde generas embeddings de muchos documentos y luego consultas contra ellos. AWS afirma hasta un 90% de ahorro en costos comparado con bases de datos de vectores especializadas para estas cargas de trabajo, y para bases de conocimiento grandes eso hace una gran diferencia.

Por qué esto importa más que el precio

Lo primero que hace la mayoría cuando dos servicios se solapan es comparar precios. Y sí, los perfiles de costo son diferentes. Pero creo que la decisión arquitectónica es más importante que el precio por consulta.

Localidad de datos: Tus vectores operacionales deben vivir donde viven tus datos operacionales. Si el embedding de un usuario se almacena en DynamoDB junto a su perfil, puedes actualizar ambos en una sola escritura evitando datos desactualizados de un pipeline de sincronización.

Propiedad de datos: Los vectores de conocimiento frecuentemente provienen de contenido que ya vive en S3. Mantener los embeddings cerca del material fuente en S3 Vectors significa un sistema menos del cual preocuparse.

Simplicidad: Cada vez que agregas un pipeline de sincronización entre dos servicios, agregas un modo de fallo, latencia, costo y carga operacional. Elegir el vector store correcto basándote en lo que los datos representan te permite evitar esa complejidad por completo.

Latencia: DynamoDB Vector Search ofrece latencia de milisegundos de un solo dígito. Esto es muy impactante cuando haces recomendaciones en tiempo real o detección de fraude en la ruta crítica de una solicitud de usuario. S3 Vectors optimiza para throughput y costo en colecciones grandes, donde unos milisegundos extra no hacen daño.

Por qué existe DynamoDB Vector Search

Permítanme ser específico sobre qué lo hace valioso para cargas de trabajo operacionales:

• Escritura lógica única: Almacena el embedding junto al item con una llamada regular de PutItem, sin necesidad de un pipeline de ingesta separado.
• Indexación nativa: Crea un índice vectorial en un atributo y DynamoDB se encarga del resto, de la misma forma en que crearías un nuevo índice secundario global. Con el beneficio adicional de que escala horizontalmente automáticamente a medida que tus datos crecen.
• Filtros de metadatos: Reduce los resultados de búsqueda usando tus atributos existentes de DynamoDB. Por ejemplo, puedes buscar productos por similitud pero filtrar por una categoría o marketplace específico.
• Cargas de trabajo operacionales: Construido para los mismos patrones de acceso en los que DynamoDB ya sobresale, que proporcionan alto throughput, baja latencia y rendimiento predecible.
• Sin infraestructura: El mismo modelo serverless que los usuarios de DynamoDB ya conocen.

Si ya estás usando DynamoDB y quieres agregar búsqueda semántica a tu aplicación, ya no necesitas mantener una base de datos de vectores separada y el pipeline que la alimenta.

Dónde brilla S3 Vectors

Por otro lado, S3 Vectors está construido para un conjunto diferente de problemas:

• Colecciones masivas: Miles de millones de vectores a escala sin preocuparse por el aprovisionamiento
• RAG empresarial: Alimenta tus pipelines de generación aumentada por recuperación con grandes bases de conocimiento
• Optimización de costos: Cuando tienes millones de documentos con embeddings generados y mayormente inactivos, el modelo de costos de S3 Vectors es difícil de superar
• Embeddings de larga duración: Documentos que se procesan una vez y se consultan muchas veces durante meses o años

Si estás construyendo una base de conocimientos para tus agentes o un sistema de búsqueda de documentación, S3 Vectors es la opción natural.

El modelo mental

Así es como lo pienso ahora:

Si tus vectores representan…	Considera
Usuarios	DynamoDB Vector Search
Productos	DynamoDB Vector Search
Recomendaciones	DynamoDB Vector Search
Memoria de sesión	DynamoDB Vector Search
Señales de fraude	DynamoDB Vector Search
PDFs	S3 Vectors
Documentación	S3 Vectors
Bases de conocimiento	S3 Vectors
Artículos de soporte	S3 Vectors

La forma más simple en que puedo decirlo: si los datos son algo que tu aplicación muta activamente y consulta en tiempo real, son operacionales y DynamoDB Vector Search es la opción perfecta. Si los datos son algo que procesas una vez y recuperas muchas veces como contexto, son conocimiento y deberías usar S3 Vectors.

Conclusión

Volviendo a la pregunta con la que empecé: ¿por qué AWS lanzó otro vector store?

La respuesta es que AWS no está simplemente agregando más bases de datos de vectores al catálogo, están llevando capacidades vectoriales a los almacenamientos que los desarrolladores ya usan. Los usuarios de DynamoDB no deberían tener que salir de DynamoDB para hacer búsqueda por similitud en sus datos operacionales, y los usuarios de S3 no deberían tener que crear una base de datos separada para buscar en los embeddings de sus documentos.

No se trata de qué servicio es mejor, se trata de qué modelo de datos se ajusta a tus vectores.

¡Dime qué piensas sobre esta distinción! Me encantaría escuchar cómo otros están pensando sobre dónde poner sus vectores.

Andres Moreno