Présentation de l’intégration

AWS a ajouté le moteur analytique open‑source DuckDB au sein d’Aurora PostgreSQL. Cette extension, nommée aurora_analytics, permet d’interroger directement des tables Iceberg et des fichiers Apache Parquet stockés dans Amazon S3 depuis une instance Aurora. L’objectif déclaré est de supprimer les pipelines ETL traditionnels qui copiaient les données historiques dans la base transactionnelle.

Architecture et mécanismes

DuckDB s’exécute à l’intérieur du processus PostgreSQL, ce qui évite les sauts réseau supplémentaires lors du scan des données du lac. Lorsqu’une requête joint des enregistrements opérationnels avec des fichiers S3, Aurora filtre les lignes et sélectionne les colonnes requises avant de transmettre les blocs de données à DuckDB. Le moteur exploite les métadonnées de fichier pour inférer automatiquement le schéma, comme illustré dans la démonstration où sept jours de transactions en Aurora ont été combinés avec cinq ans de données historiques au format Parquet.

Le support des catalogues externes repose sur la spécification Iceberg REST Catalog et sur le service AWS Glue. Les utilisateurs enregistrent un catalogue dans Glue, créent des tables étrangères qui pointent vers les emplacements S3, puis les joignent aux tables locales d’Aurora via du SQL standard. Les métriques exposées – lignes scannées, octets lus, taux de cache – permettent de suivre l’impact de chaque requête.

Analyse des performances et des coûts

En exécutant le scan analytique dans le même processus que la base transactionnelle, la latence passe au niveau du « single‑digit‑millisecond » pour les charges qui nécessitent un accès ponctuel aux archives. Pour les workloads plus intensifs, les utilisateurs peuvent matérialiser les résultats dans des tables Aurora natives à l’aide de commandes SQL classiques, ce qui déplace la charge vers le writer et libère les réplicas de lecture.

Le modèle tarifaire reste inchangé : aucune charge supplémentaire pour la fonctionnalité, uniquement le coût incrémental du CPU Aurora consommé et les requêtes S3 générées. Cette approche évite les dépenses liées à l’infrastructure ETL supplémentaire et à la duplication de données.

Limites et perspectives

La prise en charge actuelle se limite aux versions Aurora PostgreSQL 17.11 et 18.6, et nécessite un rôle IAM avec accès à S3 et Glue. Les requêtes qui lisent de gros volumes de fichiers restent soumises aux limites de bande passante S3 et aux performances du cache interne. De plus, la visibilité sur les optimisations internes de DuckDB reste restreinte, ce qui peut compliquer le diagnostic de goulets d’étranglement dans des environnements très complexes. Malgré ces contraintes, l’intégration montre comment AWS exploite un moteur analytique léger pour rapprocher le data‑lake et le OLTP, ouvrant la voie à des architectures hybrides où le même point d’accès SQL sert à la fois les transactions en temps réel et l’analyse historique.