AWS incorpora DuckDB en Aurora PostgreSQL para que una misma consulta combine registros operativos de la base de datos con tablas Apache Iceberg y datos Apache Parquet almacenados en Amazon S3. La función, que también permite consultar escrituras aún no confirmadas, está disponible desde Aurora PostgreSQL 17.11 y 18.6.
Aurora consulta datos operativos y datos del lago juntos
La función permite acceder desde una consulta de PostgreSQL tanto a los datos operativos de Aurora como a datos de un lago en S3, incluidos S3 Tables. Así, las aplicaciones pueden relacionar registros recientes con datos históricos sin tener que copiarlos primero a Aurora mediante un proceso ETL, es decir, uno que extrae, transforma y carga datos.
AWS describe DuckDB como el motor integrado en Aurora que procesa los análisis. Es una función gestionada de Aurora, distinta del proyecto independiente pg_duckdb.
DuckDB procesa las consultas analíticas
La integración admite datos Apache Iceberg y Apache Parquet. Para Iceberg, AWS contempla tablas gestionadas con AWS Glue Data Catalog y catálogos externos compatibles con Iceberg REST Catalog, que pueden registrarse mediante Glue.
En una consulta, Aurora puede combinar esos datos con los registros operativos, incluidas escrituras todavía no confirmadas. El objetivo es facilitar el acceso conjunto a datos de la aplicación y a datos históricos del lago.
Versiones y configuración necesarias
AWS indica que la función es compatible con Aurora PostgreSQL 17.11 en adelante y 18.6 en adelante. Para habilitarla, se necesita la extensión aurora_analytics y un rol de AWS Identity and Access Management (IAM) con la característica AuroraAnalytics. Ese rol concede a Aurora acceso a S3 y AWS Glue.
Cómo se ejecutan las consultas y cuándo materializar datos
AWS describe optimizaciones como el filtrado de predicados, que permite aplicar condiciones a los datos consultados, la selección de columnas y la caché. La función aurora_analytics_stat_statements() permite consultar métricas por consulta, entre ellas las filas analizadas, los bytes leídos de S3 y los accesos a la caché.
Las consultas de lectura pueden ejecutarse en la instancia escritora o en una réplica de lectura. En cambio, los comandos que materializan datos —es decir, los guardan en tablas nativas de Aurora— se ejecutan en la instancia escritora. AWS plantea esta opción para patrones de consulta que necesitan latencias de milisegundos de un solo dígito; esa cifra describe una necesidad de carga, no un resultado garantizado para las consultas directas al lago.
En un ejemplo de AWS, una consulta combina siete días de transacciones recientes de Aurora con cinco años de transacciones históricas en un archivo Parquet de S3. Aurora infiere el esquema de la tabla externa a partir de los metadatos del archivo. Esas ventanas corresponden al ejemplo, no a límites de la función.
Disponibilidad y costes
AWS afirma que la función está disponible en todas las regiones comerciales de AWS y en las regiones AWS GovCloud (US). No añade un cargo específico por activarla, pero el uso sí puede generar costes incrementales de cómputo de Aurora y de solicitudes a S3.
