AWS intègre DuckDB à Aurora PostgreSQL pour permettre à une même requête d’associer les données opérationnelles de la base à des tables Apache Iceberg ou à des fichiers Apache Parquet dans Amazon S3. La fonction prend en charge Aurora PostgreSQL 17.11 et 18.6, et peut ainsi éviter de recopier au préalable les données du lac dans Aurora via un pipeline ETL.
Aurora interroge ensemble les données opérationnelles et celles du lac
Une requête peut lire les données opérationnelles d’Aurora, y compris des écritures non validées, ainsi que des données Iceberg ou Parquet stockées dans S3. AWS inclut aussi les S3 Tables parmi les données accessibles. L’application et ses outils PostgreSQL peuvent donc interroger ces différentes sources sans devoir d’abord transférer les données historiques dans la base.
DuckDB, intégré à Aurora selon AWS, prend en charge les analyses. Il s’agit d’une fonction gérée d’Aurora PostgreSQL, distincte de l’extension indépendante pg_duckdb.
DuckDB et les catalogues compatibles
Pour accéder aux tables Iceberg, la fonction peut s’appuyer sur AWS Glue Data Catalog. AWS indique également que les catalogues externes compatibles avec Iceberg REST Catalog peuvent être enregistrés dans Glue, puis référencés au moyen de tables étrangères dans PostgreSQL.
Versions et configuration
La fonction prend en charge Aurora PostgreSQL à partir de la version 17.11 pour la branche 17 et de la version 18.6 pour la branche 18. Son activation nécessite l’extension aurora_analytics et un rôle IAM associé à la fonction AuroraAnalytics. Ce rôle accorde à Aurora l’accès à S3 et à AWS Glue.
Exécution des requêtes et matérialisation des données
AWS décrit plusieurs optimisations : le moteur peut pousser des filtres vers les données, ne lire que les colonnes utiles et mettre des résultats en cache. La fonction aurora_analytics_stat_statements() fournit, pour chaque requête, des mesures comme le nombre de lignes analysées, le volume de données lu dans S3 et les accès au cache.
Les requêtes de lecture peuvent s’exécuter sur l’instance principale, appelée writer, ou sur une réplique en lecture. Les commandes qui matérialisent des données dans Aurora — c’est-à-dire les enregistrent dans des tables natives de la base — s’exécutent sur le writer. Pour les requêtes qui exigent une latence inférieure à 10 ms, AWS présente la matérialisation de certaines données du lac comme une option.
Dans un exemple, AWS associe sept jours de transactions récentes dans Aurora à cinq ans d’historique conservés dans un fichier Parquet sur S3. Aurora déduit alors le schéma de la table étrangère à partir des métadonnées du fichier.
Disponibilité et coûts
AWS indique que la fonction est disponible dans toutes les régions AWS commerciales ainsi que dans AWS GovCloud (US). Elle n’entraîne pas de frais supplémentaires spécifiques, mais les coûts de calcul Aurora et les requêtes S3 supplémentaires restent à la charge des clients.
