¿Amazon S3 Vectors acabará con las bases de datos vectoriales o las salvará?
No hace mucho, AWS lanzó algo nuevo: S3 Vectors. Es su primer intento de una solución de almacenamiento vectorial, que te permite almacenar y consultar embeddings vectoriales para búsqueda semántica directamente dentro de Amazon S3.
A primera vista, parece una base de datos vectorial ligera que se ejecuta sobre almacenamiento de objetos de bajo coste, a un precio claramente atractivo en comparación con muchas soluciones dedicadas de bases de datos vectoriales.
amazon s3 vectors.png
Naturalmente, esto generó muchas opiniones contundentes. He visto a gente en redes sociales y en círculos de ingeniería decir que esto podría ser el fin de las bases de datos vectoriales creadas específicamente para este propósito, incluidas Milvus, Pinecone, Qdrant y otras. Una afirmación atrevida, ¿verdad?
Como arquitecto de ingeniería de Milvus y alguien que ha pasado demasiadas noches pensando en la búsqueda vectorial, tengo que admitir que: S3 Vectors aporta algo interesante, especialmente en torno al coste y la integración dentro del ecosistema de AWS. Pero en lugar de “matar” a las bases de datos vectoriales, lo veo encajando en el ecosistema como una pieza complementaria. De hecho, su verdadero futuro probablemente esté en trabajar con bases de datos vectoriales profesionales, no en reemplazarlas.
En esta publicación, te explicaré por qué pienso eso, analizándolo desde tres ángulos: la tecnología en sí, lo que puede y no puede hacer, y lo que significa para el mercado.
Un dato sorprendente: el almacenamiento vectorial puede costar más que las llamadas a LLM
La búsqueda vectorial es potente, pero viene con una trampa seria: es cara. Las demandas computacionales suelen ser entre uno y dos órdenes de magnitud superiores a las que verías en una base de datos NoSQL típica. Esa brecha no es solo teórica: aparece en facturas reales.
Hace poco hablé con el CTO de una popular aplicación de notas con IA que me contó algo sorprendente: gastan el doble de dinero en búsqueda vectorial que en llamadas a la API de OpenAI. Piensa en eso por un segundo. Ejecutar la capa de recuperación les cuesta más que pagar por el propio LLM. Eso pone patas arriba la suposición habitual.
El auge de ChatGPT en 2022 solo hizo que esto fuera más evidente. De repente, los embeddings estaban por todas partes, y los datos vectoriales se convirtieron en el tipo de datos de más rápido crecimiento en la nube pública. Retrieval-Augmented Generation (RAG) fue el impulsor, y con él llegaron tres desafíos que redefinieron lo que tenía que hacer una base de datos vectorial como Milvus:
Explosión masiva de datos: Las cargas de trabajo pasaron de decenas de millones a decenas de miles de millones de vectores casi de la noche a la mañana. Eso no es un crecimiento lineal: es un salto cuántico, y rompió las formas antiguas de manejar datos.
La tolerancia a la latencia cambió: Como los LLM tardan tiempo en generar respuestas de todos modos, los usuarios se volvieron más tolerantes a una recuperación ligeramente más lenta. La mentalidad de “recall por debajo de 10 ms a toda costa” de repente importaba menos.
La sensibilidad al coste se disparó: Duplicar o triplicar el volumen de datos no era solo un problema de almacenamiento; se convirtió en una crisis financiera si intentabas escalar usando diseños tradicionales intensivos en cómputo.
En resumen: las bases de datos vectoriales tuvieron que evolucionar rápido, no porque la tecnología no funcionara, sino porque la economía de la recuperación de repente pasó a estar en primer plano.
La evolución del almacenamiento vectorial: de la memoria al disco, y ahora al almacenamiento de objetos
La presión en torno al coste y la escala forzó una conclusión: las bases de datos vectoriales no podían seguir siendo solo en memoria para siempre. Tenían que evolucionar: primero al disco, y ahora al almacenamiento de objetos como S3. No fue una elección; fue una inevitabilidad de la industria. Y si has estado siguiendo este espacio, probablemente hayas notado la misma tendencia que yo durante los últimos años.
He visto a las bases de datos vectoriales pasar por tres etapas distintas:
Fase I (2018–2022): La era de la memoria pura: En los primeros días de Milvus, nos apoyábamos en índices en memoria como HNSW e IVF. El rendimiento y la recuperación eran fantásticos, pero los costos eran brutales. La memoria no escala de forma económica, y todos los que pagaban esas facturas de la nube lo sabían.
Fase II (2022–2024): La revolución de los índices en disco: Para romper el cuello de botella de la memoria, fuimos pioneros en un enfoque basado en disco usando DiskANN junto con nuestro índice propietario Cardinal (exclusivo de Zilliz Cloud, el Milvus gestionado). Con trucos como E/S asíncrona (AIO) e io_uring, logramos exprimir un rendimiento real de los discos. ¿El resultado? Una reducción de costos de 3–5x. Nuestras unidades de cómputo (CU) optimizadas para capacidad se convirtieron rápidamente en superventas en Zilliz Cloud.
Fase III (2024– ): La era del almacenamiento por niveles: El siguiente paso era obvio: llevar los índices vectoriales al almacenamiento de objetos barato. Nuevos actores como TurboPuffer apostaron de lleno por S3, reduciendo los costos de almacenamiento a ~$0.33/GB/mes: una reducción de 10x. Pero la contrapartida era igual de clara: latencia de consultas en frío en el rango de 500ms–1s, y una precisión de recuperación más débil.
En Zilliz, llevamos tiempo trabajando en el almacenamiento por niveles, pero retrasamos el lanzamiento hasta poder controlar el rendimiento de las consultas en frío. El mes que viene, lanzaremos nuestras CU de capacidad extendida actualizadas con una verdadera separación caliente/frío en Zilliz Cloud. Eso significa una latencia estable de consultas en frío por debajo de 500ms, combinada con QPS ultraaltas para consultas en caliente. En otras palabras, lo mejor de ambos mundos.
Amazon S3 Vectors llega justo a tiempo
Con el almacenamiento por niveles ya demostrando su valor, no sorprende que AWS entrara con S3 Vectors. De hecho, el lanzamiento se siente como una extensión natural de lo que ya estaba ocurriendo en toda la industria. Amazon había estado ampliando el papel de S3 con funciones como S3 Tables, evolucionándolo de “solo almacenamiento de objetos” a una columna vertebral de almacenamiento en frío multimodal. Los vectores son simplemente la siguiente modalidad en esa evolución, y probablemente no se detendrá ahí. Los grafos, los datos clave-valor y las series temporales podrían seguir todos el mismo camino.
Y Amazon aporta tres ventajas innegables:
Menor costo: entre los precios de almacenamiento más bajos de la industria.
Escala masiva: los pools de máquinas de AWS pueden absorber casi cualquier carga de consultas.
Arquitectura nativa de microservicios: perfectamente alineada con el flujo de trabajo de escritura–construcción–consulta de la indexación vectorial.
En conjunto, estas ventajas dan a S3 Vectors los ingredientes para convertirse en una solución de almacenamiento en frío para vectores de costo ultrabajo y altamente escalable.
S3 Vectors es un verdadero asesino de precios, pero con límites claros
Tan pronto como se anunció S3 Vectors, nuestro equipo lo sometió a pruebas exhaustivas. Los resultados fueron reveladores, no solo en términos de lo barato que es, sino también de dónde empiezan a aparecer las grietas.
S3 Vectors es un verdadero asesino de precios
No se puede negar: S3 Vectors es increíblemente rentable.
El almacenamiento cuesta solo $0.06/GB, aproximadamente 5 veces más barato que la mayoría de las soluciones vectoriales serverless. Para una carga de trabajo representativa —digamos 400 millones de vectores más 10 millones de consultas al mes— la factura asciende a unos $1,217/mes. Eso supone una reducción de más de 10x en comparación con las bases de datos vectoriales tradicionales. Para cargas de trabajo de bajo QPS y tolerantes a la latencia, es casi imbatible.
Pero el rendimiento tiene restricciones reales
Límites de tamaño de colección: Cada tabla de S3 tiene un máximo de 50M de vectores, y solo puedes crear hasta 10,000 tablas.
Consultas en frío: La latencia se sitúa en ~500ms para 1M de vectores y ~700ms para 10M de vectores.
Consultas en caliente: La latencia se mantiene por debajo de 200ms a 200 QPS, pero superar ese techo de 200 QPS es difícil.
Rendimiento de escritura: Limitado a menos de 2MB/s. Eso es órdenes de magnitud inferior a Milvus (que maneja GB/s), aunque, para ser justos, las escrituras no degradan el rendimiento de las consultas. Traducción: no está diseñado para escenarios con conjuntos de datos grandes y que cambian con frecuencia.
Compromisos entre precisión y funcionalidad
La cuestión de la precisión es donde las cosas se complican. El recall ronda el 85–90%, y no tienes controles para ajustarlo a un valor más alto. Añade filtros, y el recall puede caer por debajo del 50%. En una prueba en la que eliminamos el 50% de los datos, las consultas TopK pedían 20 resultados, pero solo podían devolver 15.
La funcionalidad también está reducida. Las consultas TopK tienen un máximo de 30. Los metadatos por registro tienen límites estrictos de tamaño. Y no encontrarás funciones como búsqueda híbrida, multi-tenancy o filtrado avanzado, todas ellas imprescindibles para muchas aplicaciones de producción.
Diseccionando S3 Vectors: la arquitectura probable
Después de realizar pruebas y compararlas con patrones de diseño conocidos de AWS, nos hemos formado una hipótesis bastante sólida sobre cómo funciona S3 Vectors bajo el capó. Aunque Amazon no ha publicado detalles completos, las características de rendimiento apuntan a cinco tecnologías principales:
Indexación dinámica SPFresh: En lugar de reconstruir índices completos después de cada escritura, S3 Vectors parece actualizar solo las partes afectadas. Este diseño mantiene bajos los costes de escritura y alta la disponibilidad, pero tiene un precio: las tasas de recall bajan unos pocos puntos porcentuales después de las actualizaciones.
Cuantización profunda (PQ de 4 bits): Para reducir la sobrecarga de E/S de S3, es probable que los embeddings se compriman usando cuantización de producto de 4 bits.
La ventaja: el almacenamiento es barato y las consultas siguen siendo rápidas.
La desventaja: el recall se estanca alrededor de ~85%, y no hay controles para que los desarrolladores lo ajusten a un valor más alto.
Mecanismo de postfiltro: El filtrado parece aplicarse después de la recuperación aproximada. Eso mantiene el índice unificado y simple, pero tiene dificultades con condiciones complejas. En nuestras pruebas, cuando eliminamos el 50% de los datos, las consultas TopK que solicitaban 20 resultados devolvieron solo 15: señales clásicas de una canalización de postfiltro. Esto también sugiere que Amazon se apoyó en gran medida en diseños de índices open-source existentes en lugar de crear uno personalizado desde cero.
Caché multinivel: Las consultas en caliente se comportan mucho más rápido, probablemente gracias a una caché SSD/NVMe situada delante de S3. Pero cuando una consulta no acierta en la caché, la latencia aumenta significativamente. Ese patrón encaja con una jerarquía de caché multinivel construida para ocultar la lentitud inherente del almacenamiento de objetos.
Planificación distribuida a gran escala: A AWS no le faltan pools de máquinas. S3 Vectors parece distribuir la carga de trabajo entre microservicios, canalizando el flujo leer → descomprimir → buscar. El resultado es lo que observamos en las pruebas: una distribución de latencia notablemente estable, incluso bajo carga intensa.
Dónde encaja S3 Vectors: la herramienta adecuada para trabajos específicos
Después de poner a prueba S3 Vectors, queda claro que destaca en algunos escenarios y se queda corto en otros. Como la mayoría de las herramientas de infraestructura, no es una solución universal: es la herramienta adecuada para el trabajo adecuado.
Donde funciona bien
Archivado de datos fríos: Perfecto para almacenar conjuntos de datos históricos a los que se accede rara vez. Si puedes vivir con tiempos de consulta de más de 500ms, el ahorro de costes es imbatible.
Consultas RAG de bajo QPS: Piensa en pequeñas herramientas internas o chatbots que ejecutan solo decenas de consultas al día, manteniéndose por debajo de 100 QPS. Para estos casos de uso, la latencia no es un factor decisivo.
Prototipado de bajo coste: Excelente para proyectos de prueba de concepto en los que el objetivo es probar una idea sin gastar mucho en infraestructura.
Donde tiene dificultades
Búsqueda y recomendación de alto rendimiento: Si tu aplicación necesita una latencia inferior a 50 ms, S3 Vectors sencillamente no está diseñado para ello.
Escrituras de alto volumen o actualizaciones frecuentes: El rendimiento se degrada rápidamente, y la precisión de recuperación cae notablemente bajo una alta rotación.
Cargas de trabajo de consultas complejas: No hay soporte para búsqueda híbrida, agregaciones ni otras funciones avanzadas de consulta.
Aplicaciones de producción multiinquilino: Con un límite estricto de 10.000 buckets, no está diseñado para despliegues multiinquilino a gran escala.
En otras palabras, S3 Vectors es excelente para escenarios fríos, baratos y de bajo QPS, pero no es el motor que quieres para impulsar un sistema de recomendación, una aplicación de búsqueda en tiempo real o cualquier sistema de producción a gran escala.
El futuro es el almacenamiento vectorial por niveles
S3 Vectors no significa el fin de las bases de datos vectoriales; confirma algo que muchos de nosotros llevamos tiempo observando: el futuro es el almacenamiento por niveles. En lugar de mantener cada vector en memoria costosa o en disco rápido, las cargas de trabajo se distribuirán de forma natural entre niveles calientes, templados y fríos según la frecuencia con la que se acceda a ellos y el tipo de latencia que la aplicación pueda tolerar.
Así es como se ve en la práctica:
Capa de datos calientes (<50 ms) – Aquí es donde se encuentran la búsqueda en tiempo real, las recomendaciones y los anuncios dirigidos. La latencia debe estar por debajo de 50 ms, lo que significa que las bases de datos vectoriales especializadas siguen siendo la mejor opción. Están optimizadas tanto para una velocidad fulgurante como para un alto rendimiento de consultas.
Capa de datos templados (50–500 ms) – Muchas aplicaciones basadas en RAG y servicios compartidos multiinquilino caen aquí. Estas cargas de trabajo no necesitan latencia ultrabaja, pero sí requieren un rendimiento predecible a menor coste. S3 Vectors y las instancias de almacenamiento por niveles de Milvus encajan en este punto intermedio.
Capa de datos fríos (>500 ms) – Los archivos históricos y el análisis offline no requieren respuestas en tiempo real, por lo que una latencia de cientos de milisegundos es aceptable. Lo que importa aquí es la eficiencia de costes a escala masiva. Aquí es donde brillan soluciones como S3 + Spark/Daft o el lago de datos vectoriales de Milvus.
La división caliente–templada–fría equilibra latencia, coste y escala de una forma que ningún nivel de almacenamiento único puede cubrir por sí solo. Es un patrón que ya hemos visto antes en bases de datos relacionales, almacenes de datos e incluso CDN, y el almacenamiento vectorial ahora sigue la misma trayectoria. Esta arquitectura de tres niveles también se alinea estrechamente con la hoja de ruta que hemos estado construyendo para Milvus y Zilliz Cloud.
1. Una arquitectura unificada de procesamiento online + offline
Las aplicaciones de IA no viven ordenadamente en mundos separados “online” y “offline”. En realidad, los datos se mueven constantemente entre ambos. Por eso, con el próximo Milvus 3.0, presentaremos un lago de datos vectoriales, diseñado para soportar tanto la recuperación en tiempo real como el procesamiento offline desde el mismo conjunto de datos.
En la práctica, esto significa que un único conjunto de datos puede alimentar tus consultas RAG y de búsqueda en vivo, al tiempo que también se integra en análisis offline basados en Spark; por ejemplo, para curar datos de entrenamiento para LLMs. Sin duplicación, sin tener que manejar dos pipelines diferentes.
También lanzaremos el formato StorageV2 para el lago de datos vectoriales, que lleva la economía a otro nivel:
Hasta 100 veces más barato para el almacenamiento de datos fríos.
Hasta 100 veces más rápido que las consultas Spark por fuerza bruta sobre datos calientes.
El resultado es un sistema unificado que minimiza la redundancia, mantiene los costes bajo control y hace que trabajar con datos vectoriales sea mucho menos doloroso.
2. Crear funciones que los desarrolladores de IA realmente necesitan
Durante los últimos dos años, las aplicaciones de IA han avanzado rápidamente, y también lo han hecho los requisitos de la infraestructura que las sustenta. En Zilliz, hemos impulsado Milvus en consonancia con esas necesidades, lanzando capacidades como la búsqueda híbrida BM25 + vectorial, el aislamiento multi-tenant, el almacenamiento por niveles hot–cold y la deduplicación con MinHash, junto con una larga lista de mejoras enfocadas en los desarrolladores.
Nuestra filosofía ha sido sencilla: cuando combinas una comprensión profunda de los casos de uso empresariales con la tecnología más reciente, desbloqueas posibilidades de infraestructura completamente nuevas. Esa es la mentalidad que da forma a Milvus 3.0, que traerá una nueva ola de funciones nativas de IA diseñadas directamente para aplicaciones del mundo real. Entre ellas:
Ponderación de palabras clave en la búsqueda – Para que una consulta como “teléfono rojo” pueda priorizar rojo adecuadamente.
Soporte de geolocalización – Almacena y consulta vectores sensibles a la ubicación para manejar prompts como “encontrar cafeterías cercanas.”
Soporte multivectorial para RAG – Adjunta múltiples embeddings a cada texto, mejorando la recuperación y la precisión en tareas de recuperación complejas.
Procesamiento UDF flexible – Funciones definidas por el usuario para un procesamiento de datos más rico y personalizable.
Herramientas de análisis visual – Minería offline y exploración de datos más profundas a escala.
Y eso es solo el comienzo. El punto más importante es que Milvus está evolucionando hacia un sistema que no solo es eficiente y escalable, sino nativo de IA en su núcleo: diseñado específicamente para cómo funcionan realmente las aplicaciones modernas.
3. Ingeniería para escalar sin un precio elevado
En Zilliz, creemos que: una reducción de costos de 10x abre la puerta a 100x más casos de uso de aplicaciones. Ese principio ha guiado cada gran hito en Milvus. Desde 2022, hemos introducido índices basados en disco, aceleración por GPU y cuantización RabitQ, todo lo cual ha aumentado el rendimiento de las consultas en órdenes de magnitud mientras reduce los costos.
De cara al futuro, nuestro enfoque está en extraer aún más eficiencia de la pila:
Optimización de hardware más profunda – Ajuste para la potencia de cómputo bruta y el rendimiento de IOPS.
Compresión y cuantización más inteligentes – Hacer que los vectores sean más ligeros sin sacrificar precisión.
Terminación anticipada para consultas de índices – Cortar el cómputo desperdiciado tan pronto como tengamos resultados confiables.
Indexación por niveles refinada – Mejor utilización de la caché para un acceso más rápido a datos fríos.
El objetivo final no ha cambiado: construir infraestructura que simplemente funcione desde el primer momento, escale bajo demanda y siga siendo rápida y asequible.
Por qué la llegada de S3 Vectors es una buena noticia para todos
A mucha gente le preocupa que S3 Vectors vuelva obsoletas a las bases de datos vectoriales tradicionales. Mi opinión es la contraria: su lanzamiento es una buena noticia para toda la industria. De hecho, veo tres grandes beneficios.
Valida la demanda. Ya nadie puede afirmar que los vectores son solo una moda pasajera. Si AWS está construyendo un producto en torno a ello, eso es una prueba irrefutable de que el almacenamiento vectorial es una necesidad real, no solo “índices envueltos en una base de datos.”
Educa al mercado. Con el alcance de AWS, más empresas ahora conocen las bases de datos vectoriales, lo que amplía los límites de las aplicaciones que se pueden construir.
Impulsa la innovación. La competencia nos empuja a todos —Milvus incluido— a optimizar más, reducir aún más los costos y encontrar fortalezas diferenciadas.
Desde el punto de vista del posicionamiento, S3 Vectors parece menos una base de datos vectorial completa y más el nivel frío del almacenamiento vectorial. Su bajo costo lo hace especialmente atractivo para escenarios que antes quedaban fuera por precio: equipos pequeños que crean aplicaciones RAG, desarrolladores individuales experimentando u organizaciones que indexan conjuntos de datos masivos con solo necesidades básicas de recuperación. Eso es un verdadero desbloqueo para el ecosistema.
Personalmente, también quiero reconocer al equipo de ingeniería de AWS. Han estado mejorando constantemente su plataforma —desde la depuración de Lambda hasta el rendimiento de arranque en frío— y S3 Vectors es otro ejemplo de innovación de producto bien pensada. Tengo verdadera curiosidad por ver qué construirán los desarrolladores ahora que la economía es tan favorable.
Así que no, el mercado de bases de datos vectoriales no está siendo disruptado: está madurando hacia un ecosistema por niveles donde diferentes soluciones satisfacen distintas necesidades de rendimiento y costo. Eso es bueno para las empresas, bueno para los desarrolladores y bueno para el conjunto de la infraestructura de IA.
La era dorada de las bases de datos vectoriales no ha terminado: apenas está comenzando.
Sigue leyendo
3 Easiest Ways to Use Claude Code on Your Mobile Phone
Run Claude Code from your phone with Remote Control, Happy Coder, or SSH + Tailscale. Comparison table, setup steps, and tools for typing, memory, and parallel tasks.
How to Improve Retrieval Quality for Japanese Text with Sudachi, Milvus/Zilliz, and AWS Bedrock
Learn how Sudachi normalization and Milvus/Zilliz hybrid search improve Japanese RAG accuracy with BM25 + vector fusion, AWS Bedrock embeddings, and practical code examples.
Introducing Zilliz MCP Server: Natural Language Access to Your Vector Database
Developers can easily manage and query vector databases with natural language via Zilliz MCP Server in AI-native environments.