tadata
← Retour à l'accueil

Postgres devient la porte d'entrée du lakehouse : Aurora, pg_lake, pg_duckdb et Iceberg en octobre 2026

#data-engineering#databases#data-architecture#cloud#open-source

En deux semaines autour du 1er octobre 2026, Amazon a livré les requêtes natives Iceberg et Parquet dans Aurora PostgreSQL avec un moteur DuckDB embarqué, Microsoft a maintenu pg_duckdb en préversion sur Azure Database for PostgreSQL, pg_lake, l'extension open source de Snowflake, a eu ses premières conférences, Redshift a appris à écrire des vues matérialisées Iceberg et Cloudflare a lancé Basin, une plateforme Iceberg sans frais de sortie en lecture. Le motif saute aux yeux : le point d'accès SQL que vos applications parlent déjà, Postgres, devient le moyen d'interroger le lac, et le format du lac est Iceberg partout. Cet article cartographie les options, l'architecture en dessous, et quand utiliser quoi.

Un format, plusieurs portes

tadata
Tables ApacheIceberg surstockage objet Aurora PostgreSQL +DuckDB embarqué tables étrangères, GA le 30 sept. pg_lake (Snowflake,open source) lecture et écriture, pgduck_server pg_duckdb sur AzurePostgreSQL préversion, par session Vues matérialiséesIceberg de Redshift écrit dans S3 + Glue, 13 oct. Databricks UnityCatalog Iceberg v3 managé, GA Snowflake Horizon(Polaris) Iceberg v3 lecture et écriture Cloudflare Basin R2 + Iceberg, GA le 1er oct. DuckDB, Spark, Trino,Athena moteurs
Tables ApacheIceberg surstockage objet Aurora PostgreSQL +DuckDB embarqué tables étrangères, GA le 30 sept. pg_lake (Snowflake,open source) lecture et écriture, pgduck_server pg_duckdb sur AzurePostgreSQL préversion, par session Vues matérialiséesIceberg de Redshift écrit dans S3 + Glue, 13 oct. Databricks UnityCatalog Iceberg v3 managé, GA Snowflake Horizon(Polaris) Iceberg v3 lecture et écriture Cloudflare Basin R2 + Iceberg, GA le 1er oct. DuckDB, Spark, Trino,Athena moteurs
Tout ce qui a été annoncé ou livré entre le 30 septembre et le 13 octobre 2026 lit ou écrit le même format de table

Les quatre façons d'interroger Iceberg depuis Postgres

tadata
VoieFonctionnementÉcriture ?Où ça tourneCoût
Aurora PostgreSQL analytics (extension aurora_analytics)Tables étrangères sur S3, S3 Tables ou le Glue Data Catalog ; DuckDB embarqué dans le processus Aurora fait le balayage avec élagage de colonnes, poussée des filtres et cache ; une requête joint les lignes vivantes (même non validées) aux données du lacNon : lecture, puis copie dans des tables natives en SQL si la latence compteAurora PostgreSQL 17.11, 18.6 et suivants, régions commerciales et GovCloudPas de frais de fonctionnalité ; calcul Aurora et requêtes S3
pg_lake (Snowflake Labs, open source, issu de Crunchy Data)Extension plus un processus séparé pgduck_server ; crée et gère des tables Iceberg, importe et exporte Parquet, CSV, JSON ; requêtes analytiques déléguées à DuckDBOui : créer, insérer, mettre à jour des tables Iceberg en SQLPostgres auto-géré, Snowflake PostgresGratuit ; votre propre calcul
pg_duckdb (DuckDB Labs et MotherDuck, open source)Moteur d'exécution DuckDB dans le backend Postgres ; duckdb.force_execution par session ; lit Parquet, Iceberg et Delta sur stockage objetÉcrit sur le stockage objet via DuckDB ; les tables Postgres restent PostgresAuto-géré ; Azure Database for PostgreSQL Flexible Server (préversion depuis novembre 2025) ; préversion Azure HorizonDBGratuit en auto-géré ; prix de l'instance Azure
Vues matérialisées Iceberg de RedshiftJointures et agrégats précalculés stockés comme tables Iceberg dans S3 et enregistrés dans Glue ; rafraîchissement incrémental des seules données modifiées ; lisibles par Athena, Spark, Trino, SnowflakeOui, comme sortie de la vueRedshiftCalcul Redshift et S3
Documentation des éditeurs et billets de lancement, lus le 14 octobre 2026

Deux choses font de l'annonce Aurora plus qu'une fonctionnalité : Amazon a conclu en août un accord pour acquérir DuckDB Labs, l'entreprise derrière DuckDB (le projet open source reste indépendant), et Aurora est le premier Postgres managé où la requête sur le lac n'exige ni extension à installer, ni second processus, ni nouveau point d'accès. Une comparaison de Franck Pachot sur dev.to montre que c'est bien DuckDB en dessous, derrière le planificateur d'Aurora, avec les mêmes forces et les mêmes limites que pg_duckdb.

Ce qu'il y a vraiment dans la boîte

tadata
Applications et BI pilotes Postgres existants pas de nouveau pointd'accès jointures SQL entredonnées vivantes et lac PostgreSQL planificateur ettransactions tables étrangères ouextension la sécurité par lignes'applique Moteur vectorisé DuckDB (Aurora, pg_lake,pg_duckdb) élagage de colonnes,poussée des filtres cache local des fichierschauds Format de table etcatalogue Iceberg v3 (lignée deslignes, VARIANT) Glue, Polaris, Unity,Horizon, catalogue R2 Stockage objet S3, S3 Tables, ADLS, R2 fichiers Parquet sortie : 0 sur R2,facturée ailleurs La pile du lakehouse Postgres
Applications et BI pilotes Postgres existants pas de nouveau pointd'accès jointures SQL entredonnées vivantes et lac PostgreSQL planificateur ettransactions tables étrangères ouextension la sécurité par lignes'applique Moteur vectorisé DuckDB (Aurora, pg_lake,pg_duckdb) élagage de colonnes,poussée des filtres cache local des fichierschauds Format de table etcatalogue Iceberg v3 (lignée deslignes, VARIANT) Glue, Polaris, Unity,Horizon, catalogue R2 Stockage objet S3, S3 Tables, ADLS, R2 fichiers Parquet sortie : 0 sur R2,facturée ailleurs La pile du lakehouse Postgres

La couche importante est la troisième. L'exécuteur de Postgres est orienté ligne et mono-thread par requête ; chacun de ces produits insère un moteur vectorisé pour balayer le Parquet, et c'est à chaque fois DuckDB. C'est pourquoi les promesses de performance se ressemblent d'un éditeur à l'autre, et les limites aussi : les grosses jointures entre deux tables du lac sont le travail de DuckDB, pas de Postgres, et la mémoire de l'instance Postgres est le plafond.

Avant et après

tadata
Analytique sur le lac en 2024 ✗ Un ETL nocturne copie les tablesopérationnelles vers l'entrepôt ; lesanalystes voient la veille ✗ Un second dialecte SQL et un second pointd'accès (Athena, Spark SQL) pour lesdonnées du lac ✗ Joindre les commandes vivantes àl'historique suppose d'exporter un des deuxcôtés ✗ Des frais de sortie dès qu'un autre cloudou un autre outil lit le lac Analytique sur le lac en octobre 2026 ✓ Les tables étrangères Postgres lisentIceberg sur place ; la jointure tient enune requête ✓ Un dialecte, une chaîne de connexion, lasécurité par ligne existante ✓ Lignes vivantes, y compris non validées surAurora, jointes à l'historique du lac ✓ Redshift écrit des vues Iceberg queSnowflake et Trino lisent ; les lecturesBasin ne coûtent rien à déplacer
Analytique sur le lac en 2024 ✗ Un ETL nocturne copie les tablesopérationnelles vers l'entrepôt ; lesanalystes voient la veille ✗ Un second dialecte SQL et un second pointd'accès (Athena, Spark SQL) pour lesdonnées du lac ✗ Joindre les commandes vivantes àl'historique suppose d'exporter un des deuxcôtés ✗ Des frais de sortie dès qu'un autre cloudou un autre outil lit le lac Analytique sur le lac en octobre 2026 ✓ Les tables étrangères Postgres lisentIceberg sur place ; la jointure tient enune requête ✓ Un dialecte, une chaîne de connexion, lasécurité par ligne existante ✓ Lignes vivantes, y compris non validées surAurora, jointes à l'historique du lac ✓ Redshift écrit des vues Iceberg queSnowflake et Trino lisent ; les lecturesBasin ne coûtent rien à déplacer

Ce qui n'a pas changé : le lac reste surtout en ajout, la lignée des lignes d'Iceberg v3 rend la capture de changements plus propre mais ne transforme pas le stockage objet en base transactionnelle, et l'instance Postgres doit toujours être dimensionnée pour les balayages que vous lui faites faire.

Quelle voie pour quelle équipe

tadata
  • Interroger Iceberg depuis Postgres ?
    • → Déjà sur Aurora PostgreSQL 17 ou 18 ?
      • oui: Activer aurora_analytics ; tables étrangères sur S3 Tables ou Glue
      • non: Besoin d'écrire des tables Iceberg depuis Postgres ?
        • oui: pg_lake sur Postgres auto-géré (ou Snowflake Postgres)
        • non: Sur Postgres managé Azure ?
          • oui: Préversion pg_duckdb sur Flexible Server ; force_execution par session
          • non: pg_duckdb auto-géré, ou garder DuckDB et Trino hors de Postgres

À faire et à éviter

tadata
✓ Do ✓ Garder un seul catalogue de référence (Glue,Polaris, Unity ou Horizon) et y brancherchaque moteur deux catalogues, deux vérités ✓ Partitionner et trier les tables Icebergselon les prédicats que Postgres poussera ✓ Matérialiser les données chaudes du lac dansdes tables natives quand la latence compte Aurora documente ce schéma comme prévu ✓ Mesurer les lignes balayées et les octets lusdepuis S3 par requête ; Aurora expose lesdeux ✓ Chiffrer la sortie avant de déplacer le lac :les lectures gratuites de Basin n'annulentpas les frais de sortie de votre fournisseuractuel ✗ Don't ✗ Faire passer de grosses jointures lac-à-lacpar un primaire Postgres de production la mémoire de l'instance est le plafond ; utilisez unréplica de lecture ou un moteur séparé ✗ Traiter Iceberg comme une basetransactionnelle parce que Postgres saitmaintenant y écrire ✗ Mélanger pg_duckdb et pg_lake sur un mêmeserveur les deux veulent le moteur DuckDB et se marchent dessusen configuration ✗ Supposer qu'une préversion Azure est sanssurprise pg_duckdb exige shared_preload_libraries et unredémarrage ; toujours en préversion Exploiter un lakehouse Postgres
✓ Do ✓ Garder un seul catalogue de référence (Glue,Polaris, Unity ou Horizon) et y brancherchaque moteur deux catalogues, deux vérités ✓ Partitionner et trier les tables Icebergselon les prédicats que Postgres poussera ✓ Matérialiser les données chaudes du lac dansdes tables natives quand la latence compte Aurora documente ce schéma comme prévu ✓ Mesurer les lignes balayées et les octets lusdepuis S3 par requête ; Aurora expose lesdeux ✓ Chiffrer la sortie avant de déplacer le lac :les lectures gratuites de Basin n'annulentpas les frais de sortie de votre fournisseuractuel ✗ Don't ✗ Faire passer de grosses jointures lac-à-lacpar un primaire Postgres de production la mémoire de l'instance est le plafond ; utilisez unréplica de lecture ou un moteur séparé ✗ Traiter Iceberg comme une basetransactionnelle parce que Postgres saitmaintenant y écrire ✗ Mélanger pg_duckdb et pg_lake sur un mêmeserveur les deux veulent le moteur DuckDB et se marchent dessusen configuration ✗ Supposer qu'une préversion Azure est sanssurprise pg_duckdb exige shared_preload_libraries et unredémarrage ; toujours en préversion Exploiter un lakehouse Postgres

En résumé

Pour une équipe dont les applications vivent dans Postgres, la question « faut-il un entrepôt ? » a désormais une réponse intermédiaire : garder le lac en Iceberg, garder l'application dans Postgres, et laisser un moteur DuckDB dans Postgres relier les deux pour les requêtes qui ont besoin des deux. Aurora en fait une case à cocher sur AWS ; pg_lake et pg_duckdb en font un déploiement ailleurs ; Redshift et Basin rendent le lac lisible depuis tous les autres moteurs sans le copier. Notre article sur DuckDB et le cadre de décision lakehouse ou entrepôt expliquent le moteur et l'économie derrière.

Sources : AWS What's New et AWS Blog sur les requêtes Iceberg et Parquet d'Aurora PostgreSQL (30 septembre 2026) ; AWS Weekly Roundup du 13 octobre 2026 (vues matérialisées Iceberg de Redshift) ; dépôt Snowflake-Labs/pg_lake et conférence POSETTE 2026 ; Microsoft Tech Community sur pg_duckdb pour Azure Database for PostgreSQL ; blog Cloudflare sur Basin (1er octobre 2026) ; notes de version Databricks d'octobre 2026 ; Data This Week numéros 33 et 34. Lus le 14 octobre 2026.

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.