DuckLake 1.0 et Iceberg v3 : guide lakehouse 2026

Pendant des années, construire un lakehouse revenait à assembler un petit système distribué : un cluster Spark, un service de catalogue, un format de table, et un job de compaction pour nettoyer les dégâts que les trois produisaient ensemble. En 2026, cette hypothèse a fini par céder. Deux sorties à quelques semaines d'intervalle — DuckLake v1.0 en avril et DuckDB-Iceberg v1.5.3 avec le support complet d'Iceberg v3 en mai — permettent désormais de faire tourner un lakehouse sérieux, transactionnel et ACID, depuis un moteur mono-nœud qui s'installe en une commande.

Ce guide passe en revue ce qui a changé, en quoi les deux formats diffèrent, et comment choisir pour un projet réel.

Un lakehouse, sans le cluster

Un lakehouse stocke les données sous forme de fichiers ouverts (presque toujours Parquet) sur un stockage objet, en y superposant des garanties de base de données : transactions ACID, évolution de schéma, time travel et écritures concurrentes. La difficulté n'a jamais été la donnée elle-même — Parquet est solide depuis une décennie. La difficulté, ce sont les métadonnées : savoir quels fichiers appartiennent à quelle version de quelle table, et coordonner les écrivains pour qu'ils ne se corrompent pas mutuellement.

Apache Iceberg a résolu le problème avec des fichiers de métadonnées stockés à côté des données, plus un service de catalogue qui pointe vers la version courante. DuckLake, publié par l'équipe DuckDB, pose une question plus simple : si vous avez de toute façon besoin d'une base de données pour coordonner le catalogue, pourquoi ne pas mettre toutes les métadonnées dans cette base et abandonner complètement le jonglage de fichiers ?

DuckLake 1.0 : les métadonnées vivent dans une base

DuckLake v1.0 est sorti le 13 avril 2026 comme spécification prête pour la production, avec rétrocompatibilité garantie. L'implémentation de référence est l'extension ducklake de DuckDB v1.5.2, déjà dans le top 10 des extensions DuckDB les plus téléchargées.

Le principe : les fichiers de données sont du Parquet ordinaire sur stockage objet, et chaque métadonnée — snapshots, schémas, listes de fichiers, statistiques — vit sous forme de lignes dans une base SQL servant de catalogue. Ce catalogue peut être SQLite pour un projet local, PostgreSQL pour une équipe multi-écrivains, ou DuckDB lui-même.

Trois instructions suffisent pour démarrer :

INSTALL ducklake;
 
ATTACH 'ducklake:postgres:dbname=lake_catalog host=db.internal'
    AS lake (DATA_PATH 's3://mon-bucket/lake/');
 
CREATE TABLE lake.orders (id INT, status VARCHAR, total DECIMAL(10,2));

À partir de là, tout se comporte comme une base classique — insertions, mises à jour, suppressions, jointures, le tout transactionnel — pendant que les données atterrissent en fichiers Parquet lisibles par n'importe quel outil.

L'inlining de données élimine le problème des petits fichiers

La fonctionnalité phare de la v1.0 est le data inlining, désormais activé par défaut. Les petites insertions, mises à jour et suppressions sont stockées comme lignes dans la base catalogue au lieu de produire chacune un minuscule fichier Parquet. Un checkpoint les vide ensuite vers le stockage objet par lots raisonnables :

CREATE TABLE lake.t (id INT, status VARCHAR);
INSERT INTO lake.t VALUES (1, 'en route'), (2, 'shipped');
DELETE FROM lake.t WHERE id = 1;
UPDATE lake.t SET status = 'delivered' WHERE id = 2;
 
FROM ducklake_list_files('lake', 't');  -- vide : aucun fichier écrit
CHECKPOINT;                             -- les données sont maintenant en Parquet

C'est le problème des « petits changements » qui afflige tous les formats de table basés sur des fichiers, résolu simplement parce qu'une base de données est disponible. Cela rend aussi l'ingestion en streaming vers un lac praticable sans service de compaction.

Tables triées, partitionnement par bucket et types enrichis

La v1.0 apporte aussi les tables triées (ALTER TABLE ... SET SORTED BY (id ASC)) pour un meilleur élagage de fichiers et de row groups, et un partitionnement par bucket qui utilise délibérément le hash murmur3 pour une compatibilité totale avec Iceberg :

ALTER TABLE lake.events SET PARTITIONED BY (bucket(8, user_name));

Le système de types s'enrichit également : un type GEOMETRY avec pushdown de filtres par bounding box, et un type VARIANT pour les données semi-structurées — encodage binaire, « shreddable » en colonnes primitives, avec support des dates et timestamps que JSON ne sait pas représenter. L'équipe DuckDB estime que VARIANT remplacera à terme JSON comme type par défaut du semi-structuré, et la communauté Iceberg a fait le même pari.

Iceberg v3 : la spécification rattrape son retard

Apache Iceberg v3 est la plus grosse révision du format de table dominant depuis des années, et 2026 est l'année où elle est devenue concrète : disponibilité générale sur Snowflake depuis mai et sur Databricks Runtime 18, le reste de l'écosystème suivant. Les apports majeurs :

Vecteurs de suppression binaires. À la place des fichiers de positional deletes de la v2, chaque fichier de données reçoit un bitmap Roaring compressé (stocké en fichiers Puffin) marquant les lignes supprimées — merge-on-read nettement plus rapide et beaucoup moins de petits fichiers.
Type VARIANT. Le même type semi-structuré binaire que DuckLake a adopté, défini dans le projet Parquet, avec shredding compatible pushdown.
Lignage de lignes. Suivi au niveau ligne des ajouts et modifications, ouvrant la voie au traitement incrémental et aux flux de changements.
Valeurs par défaut de colonnes et TIMESTAMP_NS. Évolution de schéma sans réécrire les fichiers, et timestamps à la nanoseconde.

Si vous exploitez des tables Iceberg aujourd'hui, la v3 est la mise à niveau qui rend les mises à jour et suppressions fréquentes abordables.

DuckDB comme client Iceberg v3

Le second volet de l'histoire : DuckDB-Iceberg v1.5.3 fait de DuckDB un véritable client Iceberg en lecture-écriture — implémenté nativement dans l'extension, sans dépendance à des bibliothèques Iceberg tierces ni à une JVM. Face à n'importe quel catalogue REST Iceberg (Polaris, Lakekeeper, Amazon S3 Tables, Glue), DuckDB supporte désormais MERGE INTO, l'évolution de schéma via ALTER TABLE, les transformations de partition bucket et truncate, et les lectures et écritures Iceberg v3 complètes :

ATTACH 'warehouse' AS my_datalake (TYPE iceberg, ...);
 
-- Créer une table v3 avec VARIANT et timestamps nanoseconde
CREATE TABLE my_datalake.default.v3_table
WITH ('format-version' = 3) AS
FROM (VALUES
    (1, {'kind': 'click', 'x': 10}::VARIANT, TIMESTAMP_NS '2026-05-20 12:00:00.123456789'),
    (2, {'kind': 'view'}::VARIANT,           TIMESTAMP_NS '2026-05-20 12:00:00.987654321')
) t (id, payload, event_time);
 
-- Les suppressions sont écrites en vecteurs de suppression binaires compacts
DELETE FROM my_datalake.default.v3_table WHERE id = 1;
 
-- Mettre à niveau une table existante sur place
ALTER TABLE my_datalake.default.renamed_table SET ('format-version' = 3);

MERGE INTO mérite une mention spéciale : c'est la façon recommandée d'exprimer des upserts sur des tables sans clé primaire — c'est-à-dire toutes les tables de lakehouse — et cela fonctionne désormais de bout en bout contre Iceberg depuis DuckDB.

DuckLake ou Iceberg ? Les deux, en réalité

En 2026, le choix est moins binaire qu'il n'y paraît :

Choisissez DuckLake quand votre équipe contrôle la pile et veut l'exploitation la plus simple possible : une base Postgres comme catalogue (peut-être l'instance PostgreSQL 18 que vous exploitez déjà), du Parquet sur n'importe quel stockage objet, aucun service supplémentaire. Les petites écritures en streaming, les configurations DuckDB multi-joueurs et les lacs en lecture seule servis en simple HTTPS fonctionnent d'emblée.
Choisissez Iceberg quand la portée écosystème prime — Snowflake, Databricks, Spark, Trino et Flink le parlent tous — ou quand les tables existent déjà et que d'autres équipes en dépendent.
L'interopérabilité est prévue dès la conception. DuckLake stocke ses données en Parquet avec un hachage de buckets compatible Iceberg et des vecteurs de suppression Puffin. La fonction iceberg_to_ducklake effectue une migration des métadonnées seules d'un catalogue Iceberg entier vers DuckLake — aucun fichier de données copié — et la copie de DuckLake vers Iceberg est également supportée.

Un schéma que nous recommandons de plus en plus : DuckLake comme couche opérationnelle rapide détenue par une équipe, publiant des tables validées vers Iceberg où le reste de l'organisation les consomme.

Pourquoi cela compte pour les équipes légères

Pour les startups et PME en Tunisie, dans le Golfe et ailleurs, le frein historique à l'architecture lakehouse était le coût opérationnel : des clusters à surveiller et des services de catalogue à sécuriser, pour des volumes de données qui les justifiaient rarement. Cette excuse a disparu. Un processus DuckDB, un catalogue Postgres et un bucket compatible S3 offrent désormais des tables ACID, du time travel et des formats ouverts — des téraoctets de données et des millions de snapshots sont explicitement dans les clous de la spécification. Si vous bâtissez une stratégie data d'entreprise pour l'IA, cette pile est la fondation crédible la moins chère que nous ayons jamais pu recommander.

Vous planifiez une plateforme data, ou la migration de vos analyses hors des tableurs vers un lakehouse ? Parlez à l'équipe Noqta — nous concevons et construisons des infrastructures data pour les équipes de la région MENA.