pg_lake - une extension qui permet à Postgres d’accéder à Iceberg et aux data lakes

 (github.com/Snowflake-Labs)
3 points par GN⁺ 2025-11-05 | 1 commentaires | Partager sur WhatsApp
  • pg_lake est une extension basée sur Postgres qui intègre directement les tables Iceberg et les fichiers de data lake afin de prendre en charge les transactions et les requêtes rapides
  • Permet de consulter, importer et exporter directement des fichiers Parquet, CSV, JSON et Iceberg stockés sur un object storage comme S3
  • Utilise en interne le moteur de requête DuckDB pour garantir de hautes performances d’exécution dans l’environnement Postgres
  • Fournit, via une interface SQL unique, des fonctions de lakehouse comme la création de tables Iceberg, l’inférence automatique de schéma pour les fichiers externes et les entrées/sorties S3 via la commande COPY
  • Rendu open source par Snowflake après l’acquisition de Crunchy Data en 2025, ce qui pose une base pour étendre l’intégration des data lakes dans l’écosystème Postgres

Aperçu de pg_lake

  • pg_lake est une extension qui intègre Iceberg et les fichiers de data lake dans Postgres, permettant d’utiliser Postgres comme un système de lakehouse autonome
    • Garantit les transactions sur les tables Iceberg et prend en charge des requêtes rapides
    • Permet un accès direct aux fichiers de données brutes sur un object storage comme S3
  • Principales fonctionnalités
    • Création et modification de tables Iceberg, interrogeables depuis d’autres moteurs
    • Consultation et importation de fichiers de données aux formats Parquet, CSV, JSON et Iceberg
    • Export des résultats de requête vers un object storage aux formats Parquet, CSV et JSON via la commande COPY
    • Lecture de formats de données géospatiales comme GeoJSON et Shapefile pris en charge par GDAL
    • Fournit un type map intégré pour les données semi-structurées
    • Permet de combiner des heap, Iceberg et des fichiers externes dans une seule requête SQL
    • Inférence automatique des colonnes et des types depuis des sources de données externes
    • Exécution rapide via le moteur DuckDB

Installation et configuration

  • Méthodes d’installation
    • Exécution simple avec Docker
    • Installation manuelle ou mise en place d’un environnement de développement via une compilation depuis les sources
  • Exemple de création de l’extension 
    CREATE EXTENSION pg_lake CASCADE;
    • Extensions associées : pg_lake_table, pg_lake_engine, pg_extension_base, pg_lake_iceberg, pg_lake_copy
  • pgduck_server
    • Processus autonome qui implémente le protocole wire Postgres et utilise DuckDB en interne
    • Fonctionne sur le port 5332 par défaut et peut être joint directement avec psql
    • Principaux réglages
      • --memory_limit : limite mémoire (80 % de la mémoire système par défaut)
      • --init_file_path : spécifie le fichier SQL à exécuter au démarrage
      • --cache_dir : spécifie le répertoire de cache des fichiers distants
  • Configuration de la connexion S3
    • Utilise le secrets manager de DuckDB pour reconnaître automatiquement les identifiants AWS/GCP
    • Exemple de définition de l’emplacement de stockage des tables Iceberg 
      SET pg_lake_iceberg.default_location_prefix TO 's3://testbucketpglake';

Exemples d’utilisation

  • Création d’une table Iceberg 
    CREATE TABLE iceberg_test USING iceberg AS   
SELECT i as key, 'val_'|| i as val FROM generate_series(0,99)i;
    • Après création, SELECT count(*) FROM iceberg_test; renvoie 100
    • Il est possible de vérifier l’emplacement des métadonnées Iceberg
  • Entrées/sorties COPY vers S3 
    COPY (SELECT * FROM iceberg_test) TO 's3://.../iceberg_test.parquet';  
COPY iceberg_test FROM 's3://.../iceberg_test.parquet';
    • Formats pris en charge : Parquet, CSV, JSON
  • Créer une table externe à partir de fichiers S3 
    CREATE FOREIGN TABLE parquet_table()   
SERVER pg_lake   
OPTIONS (path 's3://.../*.parquet');
    • Inférence automatique des colonnes, requêtes possibles (SELECT count(*) FROM parquet_table; → 100)

Architecture

  • Composants
    • PostgreSQL + extension pg_lake
    • pgduck_server (exécution de DuckDB et implémentation du protocole Postgres)
  • Mode de fonctionnement
    • L’utilisateur se connecte à Postgres et exécute du SQL
    • Une partie des requêtes est exécutée via DuckDB de manière parallèle et orientée colonnes
    • DuckDB n’est pas embarqué à l’intérieur du processus Postgres, ce qui évite les problèmes de sûreté liés aux threads et à la mémoire
    • Il est possible d’accéder directement au moteur DuckDB via les clients Postgres standards

Liste détaillée des composants

  • pg_lake_iceberg : implémentation de la spécification Iceberg
  • pg_lake_table : implémentation d’un FDW pour les fichiers sur object storage
  • pg_lake_copy : prise en charge des entrées/sorties COPY vers le data lake
  • pg_lake_engine : module commun
  • pg_extension_base : composant de base pour d’autres extensions
  • pg_extension_updater : mise à jour automatique des extensions
  • pg_lake_benchmark : exécution de benchmarks sur les tables du lake
  • pg_map : générateur de type map généralisé
  • pgduck_server : serveur qui charge DuckDB et l’expose via le protocole Postgres
  • duckdb_pglake : ajoute à DuckDB des fonctions compatibles Postgres

Développement et historique de publication

  • Développement lancé début 2024 chez Crunchy Data pour introduire Iceberg dans Postgres
  • Initialement centré sur l’intégration de DuckDB et la fourniture de fonctionnalités aux clients de Crunchy Bridge
  • Mise en œuvre ultérieure du protocole Iceberg v2 et de la prise en charge des transactions
  • Relancé en novembre 2024 sous le nom Crunchy Data Warehouse
  • En juin 2025, Snowflake acquiert Crunchy Data, puis en novembre 2025 pg_lake est publié en open source
    • La première version publiée est la 3.0 (incluant les deux générations précédentes)
    • Un chemin de mise à niveau automatique est fourni aux utilisateurs existants de Crunchy Data Warehouse

Licence et dépendances

  • Licence Apache 2.0
  • Dépend des projets Apache Avro et DuckDB
    • Des patchs sont appliqués à Avro et aux extensions DuckDB lors de la compilation

À lire aussi

1 commentaires

 
GN⁺ 2025-11-05
Commentaires sur Hacker News
  • Je me demande s’il y a une raison de ne pas simplement utiliser DuckLake
    Ça permettrait de réduire la complexité. Il ne faut que DuckDB et PostgreSQL (pg_duckdb)
    À noter aussi la vidéo de présentation du Prof. Hannes Mühleisen : DuckLake - The SQL-Powered Lakehouse Format for the Rest of Us
    • DuckLake est un projet assez génial. Notre équipe aime aussi DuckDB. En fait, si pg_lake a pu voir le jour, c’est grâce à DuckDB
      DuckLake peut faire des choses que pg_lake basé sur Iceberg ne peut pas faire, et inversement Postgres peut faire des choses que DuckDB ne peut pas faire. Par exemple, traiter plus de 100 000 insertions d’une seule ligne par seconde
      Le traitement transactionnel n’est pas gratuit. Au lieu de mettre le moteur dans le catalogue, mettre le catalogue dans le moteur permet des transactions entre les tables analytiques et opérationnelles
      Postgres est aussi plus naturel du point de vue de la persistance et du traitement continu. On peut construire l’orchestration avec pg_cron et PL/pgSQL
      De plus, Iceberg a l’avantage d’une bonne interopérabilité avec plusieurs moteurs de requête
    • Au final, c’est une question de choix de conception. La discussion associée se trouve dans ce fil
    • J’ai vraiment essayé d’aimer DuckLake, mais en pratique j’ai eu des problèmes de maintenance. En particulier autour du catalogue pg, DuckLake renvoyait parfois des erreurs HTTP 400 sur des fichiers qu’il avait lui-même générés
      Je ne sais pas si cela venait de mon schéma d’écriture des données (insertion depuis un DataFrame Polars dans une table DuckLake) ou de la structure des tables partitionnées
      Ça allait en environnement de développement/test, mais c’était difficile à l’échelle de toute l’équipe. Du coup, je suis finalement revenu à une combinaison de fichiers Parquet partitionnés Hive et de vues DuckDB
      Je pense poster plus tard un exemple dans une issue, mais pour l’instant je manque de temps à cause d’autres priorités
  • C’est vraiment un changement majeur
    Avant, on disait souvent qu’il n’y avait pas de « Snowflake open source » sur le marché de Postgres
    L’extension Postgres de Crunchy est actuellement la solution la plus avancée du marché. Félicitations à Snowflake et à l’équipe Crunchy pour l’avoir publiée en open source
    • Honnêtement, je pense qu’il vaut mieux simplement payer Snowflake et profiter de cette excellente base de données et de son écosystème. Si l’infrastructure n’est pas au cœur de la valeur apportée au client, mieux vaut déléguer cette partie et se concentrer sur la création de choses intéressantes
  • J’aime les data lakes et les langages de requête de type SQL. Ça ressemble à une forme évoluée de la philosophie « tout est fichier »
    Sous Linux, on peut lire et écrire la configuration du système via le système de fichiers (cat /sys/..., echo ... > /sys/...)
    Avec FUSE, on peut implémenter soi-même un pilote de système de fichiers en espace utilisateur. Par exemple, monter SSH ou Google Drive et copier avec la commande cp
    Mais les systèmes de fichiers ne sont adaptés qu’aux données hiérarchiques. Les données du monde réel ont surtout une structure relationnelle
    Les data lakes permettent, via l’élégante abstraction de SQL, de traiter différentes sources de données comme une seule base de données relationnelle
    Comme beaucoup d’applications sont au fond centrées sur le CRUD, cette approche est au final bien plus efficace
  • Comment utilises-tu un data lake ? Pour moi, ce n’est pas un simple stockage mais un espace pour des travaux analytiques imprévisibles
    Dans ce cas, Postgres a ses limites. Il faut davantage de CPU et de RAM, et au bout du compte un moteur distribué devient nécessaire
    • L’idée centrale du data lake, c’est la séparation du calcul et du stockage. Postgres n’est pas la couche de calcul mais la couche d’accès
      La couche de calcul demande à Postgres « quelles sont les données actuelles pour ces clés ? » ou « quelles étaient les données il y a deux semaines ? », puis les vraies requêtes analytiques sont exécutées directement sur les fichiers Parquet
  • Quand Snowflake a racheté Crunchy Data, j’espérais qu’ils proposeraient une version managée de ce type
    Pouvoir le lancer en Docker local, c’est bien, mais j’aimerais pouvoir l’exploiter sur AWS avec une facturation intégrée au compte Snowflake
  • J’ai vraiment l’impression qu’on est en plein âge d’or de PostgreSQL
  • Je ne suis pas data engineer, mais je travaille dans un domaine proche. Je me demande si quelqu’un pourrait expliquer simplement quel problème cela résout
    • Par exemple, imaginons qu’un service accumule des logs sur S3 sous forme de fichiers Parquet. Si on veut interroger directement ces données depuis Postgres, pg_lake est utile
      On peut charger les données Parquet dans Postgres pour les interroger, et aussi faire des jointures avec les tables existantes
  • J’ai deux questions
    (1) Y a-t-il un projet de compatibilité pour utiliser la spécification DuckLake au lieu d’Iceberg ? DuckLake gère son catalogue dans des tables SQL plutôt que dans des fichiers, ce qui simplifie les écritures concurrentes et la gestion des snapshots
    (2) Est-il possible que pg_duckdb finisse par offrir la même fonctionnalité avec le temps ?
    • (1) Nous y avons pensé, mais ce n’est pas prévu pour le moment. Plutôt que d’utiliser DuckLake tel quel, nous voulons une implémentation directe dans Postgres afin de préserver les frontières transactionnelles
      Cela dit, il existe des complexités, notamment autour du traitement des données inline. Si on les résout, on peut obtenir de hautes performances transactionnelles
      (2) pg_duckdb peut réutiliser plus facilement l’implémentation de DuckLake, mais du point de vue de la gestion des ressources et de la stabilité, cette architecture me paraît moins adaptée
  • Quand on voit S3 Table Buckets, Cloudflare R2 Data Catalog, et maintenant ce projet, on a l’impression qu’Iceberg est en train de gagner
  • Si vous voulez charger facilement des données dans une base compatible Postgres Wire, je recommande sling-cli
    On peut exécuter des tâches ETL en CLI, YAML ou Python