Aurora PostgreSQL interroge directement Iceberg et Parquet avec DuckDB embarqué
AWS embarque DuckDB dans Aurora PostgreSQL pour requêter en une seule requête les données opérationnelles et celles du data lake, sans pipeline ETL. Une bascule pour les équipes qui répliquaient le lac dans Postgres.
30 septembre 2026. AWS annonce qu’Aurora PostgreSQL peut désormais interroger directement des données Apache Iceberg et Parquet stockées dans un data lake, depuis les applications et outils PostgreSQL existants. Août 2026. Amazon a signé l’acquisition de DuckLabs, l’équipe derrière DuckDB, et c’est ce moteur qui est désormais embarqué dans Aurora. 30 septembre 2026. La fonctionnalité est disponible dans toutes les régions commerciales et GovCloud, sans coût supplémentaire. Pourquoi c’est important : c’est la première intégration produit majeure de DuckDB dans un service de base de données AWS, et elle efface le pipeline de réplication entre le lac et la base opérationnelle.
DuckDB embarqué dans le moteur de la base
L’annonce concrétise une acquisition, pas une simple intégration cosmétique. Le moteur DuckDB — la base analytique open source qui exécute du SQL directement sur des fichiers Parquet, CSV ou JSON — est désormais compilé dans Aurora PostgreSQL. Le traitement des requêtes reste dans Aurora, sans saut réseau supplémentaire et sans duplication des données.
La portée est technique mais directe. Une requête peut joindre des données opérationnelles en direct, y compris des écritures non validées, avec des fichiers Iceberg ou Parquet posés dans Amazon S3 ou S3 Tables. Le tout en syntaxe PostgreSQL familière, avec les mêmes clients, outils et points d’accès qu’aujourd’hui.
La mise en place tient en quelques commandes. On crée l’extension, puis une table étrangère pointant vers le fichier distant :
CREATE EXTENSION aurora_analytics;
CREATE FOREIGN TABLE transaction_history ()
SERVER aurora_analytics_server
OPTIONS (
location 's3://<my-bucket>/finance/transaction_history.parquet',
format 'parquet'
);Deux détails méritent l’attention. Les parenthèses vides dans CREATE FOREIGN TABLE signifient qu’Aurora lit le schéma depuis les métadonnées du fichier Parquet — pas de colonnes à déclarer à la main. Et un IMPORT FOREIGN SCHEMA unique crée en bloc les tables étrangères de toutes les tables Iceberg ou Parquet d’une base du AWS Glue Data Catalog.
Une requête, deux mondes de données
L’exemple officiel illustre l’usage exact. Un commerçant garde les 7 derniers jours de transactions dans une table Aurora, et 5 ans d’historique dans un fichier Parquet sur S3. Avant, rapprocher les deux exigeait un pipeline. Désormais, une seule requête suffit — ici un UNION ALL entre la table récente et la table étrangère :
SELECT merchant, category, amount, transaction_date, 'recent' AS source
FROM recent_transactions
WHERE customer_id = 'C-1001'
UNION ALL
SELECT merchant, category, amount, transaction_date, 'historical' AS source
FROM transaction_history
WHERE customer_id = 'C-1001'
AND transaction_date >= CURRENT_DATE - INTERVAL '5 years'
ORDER BY transaction_date DESC
LIMIT 15;Sous le capot, la répartition est nette : Aurora traite les lignes opérationnelles, DuckDB exécute le scan analytique du Parquet. La frontière entre base transactionnelle et lac, qui justifiait toute une famille d’outils, devient une question de table étrangère.
La fonctionnalité va plus loin que S3. Une fédération à travers le Glue Data Catalog permet d’interroger des catalogues compatibles Iceberg REST Catalog (IRC), enregistrés une seule fois. Une requête peut alors joindre des tables Iceberg réparties sur plusieurs catalogues, sans déplacer les données ni abandonner les catalogues existants.
Le cas d’usage qui disparaît : le reverse-ETL
Le vrai changement est ce qu’on n’a plus besoin de construire. Jusqu’ici, combiner des transactions récentes avec l’historique en S3 passait par des pipelines de reverse ETL : dupliquer les données, payer l’infrastructure, et maintenir la synchronisation. Cette charge croît à mesure que les agents IA s’invitent dans les applications, car il devient impossible de prédire et de pré-répliquer chaque jeu de données dont un agent pourrait avoir besoin.
Le cas d’usage cible est limpide : tableaux de bord en temps réel, enrichissement de transactions avec un contexte historique, ou agents qui raisonnent à la fois sur le vivant et sur l’archivé — le tout derrière une seule interface SQL. L’argument d’AWS est celui de la suppression de complexité, pas d’une nouvelle fonctionnalité à apprendre.
Pour les requêtes qui exigent une latence de l’ordre de la milliseconde, la passerelle inverse existe : matérialiser les données du lac dans une table Aurora native via CREATE TABLE AS SELECT, INSERT INTO … SELECT ou MERGE INTO. La table matérialisée vit dans Aurora et se requête comme n’importe quelle table PostgreSQL, sans pipeline d’ingestion séparé.
Ce que ça optimise, et ce que ça coûte
Les optimisations sont intégrées plutôt qu’ajoutées. Aurora applique un predicate pushdown et un élagage de colonnes pour ne lire que les données pertinentes, même quand le lac grossit. Les données fréquemment consultées sont mises en cache dans l’instance, accélérant les requêtes suivantes. Une fonction aurora_analytics_stat_statements() expose par requête les métriques — lignes scannées, octets lus depuis S3, taux de cache — de quoi mesurer précisément ce que l’on économise.
Le modèle de coût est simple. Aucun frais supplémentaire pour la fonctionnalité elle-même : on paie le calcul Aurora incrémental consommé par les requêtes et les coûts de requêtes S3 pour la lecture des fichiers du lac. Le gain vient de ce qu’on ne paie plus le pipeline de réplication ni le stockage dupliqué.
La disponibilité est large mais versionnée : la fonctionnalité requiert Aurora PostgreSQL 17.11 ou 18.6 minimum. La mise en place passe par un rôle IAM portant la fonctionnalité AuroraAnalytics, qui donne à Aurora l’accès à S3 et au Glue Data Catalog — un point de contrôle de permission à cadrer dès le départ.
Un signal sur la stratégie d’AWS
L’annonce vaut au-delà du produit. En intégrant DuckDB dans Aurora, AWS pose la première pierre d’une stratégie plus large : faire du moteur analytique embarqué un pont standard entre la base opérationnelle et le lac, au lieu d’un produit à part. La formulation officielle est explicite — les améliorations futures de l’engin open source « continueront d’apporter des gains de performance et de fonctionnalités à Aurora et aux autres services AWS ».
La lecture concurrentielle est simple. Face à des offres qui vendent le lac et l’entrepôt comme deux produits distincts, AWS choisit de dissoudre la frontière côté base de données. Pour une équipe déjà engagée sur Aurora et S3, le coût de bascule est quasi nul ; pour les autres, c’est un argument de simplification de plus dans la balance.
Verdict
Si vous exécutez aujourd’hui des pipelines de reverse-ETL ou des jobs Glue pour hydrater Postgres depuis un lac, cette fonctionnalité supprime ce pipeline pour les requêtes analytiques : testez-la sur un cas réel en mesurant le gain avec aurora_analytics_stat_statements(). Si vos charges exigent une latence sous la milliseconde, matérialisez les données chaudes dans Aurora et gardez le lac pour l’historique froid — les deux chemins coexistent. Si vous êtes en multirégion ou secteur public, vérifiez la version d’Aurora déployée et cadrez le rôle AuroraAnalytics au périmètre minimal : c’est le seul vrai levier de risque dans une intégration par ailleurs sans surcoût.