DuckDB Labs a shippé DuckLake 1.0 le mois dernier et MotherDuck a câblé le support prod — un format de table lakehouse qui diverge d'Iceberg et Delta Lake d'une manière architecturalement conséquente : au lieu de métadonnées comme fichiers manifestes JSON dans le stockage objet, toutes les métadonnées et le catalogue vivent dans une base SQL. Le framing de l'équipe sur le pourquoi est direct — les métadonnées file-based dans les formats de lac mènent à de la coordination complexe, des opérations métadonnées lentes, et beaucoup de petits fichiers. Les chiffres de lancement de MotherDuck claiment 10x plus rapide en queries et 10x plus de transactions par seconde sur le hot path catalogue. Les données brutes restent en Parquet dans le stockage objet ; seul le catalogue est passé en durabilité classe-Postgres. Licence MIT. Les clients ship pour Apache DataFusion, Spark, Trino et Pandas — multi-moteur dès le jour un, pas DuckDB-locked.

Le mécanisme qui compte pour les builders, c'est le data inlining. Le small-file problem d'Iceberg est la dette de compaction chronique qui frappe chaque lakehouse en prod : tu stream quelques lignes, elles vont dans un nouveau fichier Parquet, répète dix mille fois, maintenant tes reads scannent des dizaines de milliers de tiny files jusqu'à ce que le job de compaction rattrape. Le seuil d'inlining de DuckLake par défaut à dix lignes — tout en dessous saute directement dans le catalogue SQL au lieu de spawner un nouvel objet Parquet. Les tables sorted et le bucket partitioning pour colonnes à haute cardinalité sont dans 1.0, les types geometry ont été upgradés, et les deletion vectors sont explicitement compatibles Iceberg — un vecteur émis par DuckLake se lit proprement depuis les consumers Iceberg existants. L'interop est intentionnelle ; c'est un format qui essaie de gagner sur les caractéristiques opérationnelles, pas le lock-in. Le tradeoff architectural, c'est que tu as maintenant une dépendance de disponibilité Postgres (ou compatible) sur le chemin métadonnées. Pour la plupart des builders, c'est une feature — Postgres a été tuné pour des reads basse-latence haute-concurrence depuis quarante ans. Pour les builders qui font tourner des lakehouses multi-region sans DB catalogue central évident, c'est la nouvelle question à designer autour.

Lecture ecosystem : la guerre des formats lakehouse entre Iceberg et Delta Lake a dix ans à ce stade et la réponse opérationnelle n'est pas arrivée. Iceberg a gagné la bataille de la spec métadonnées mais Delta ship encore mieux de l'outillage. DuckLake arrive d'un troisième axe — contourner entièrement le catalogue file-based. Il ne remplacera pas Iceberg dans les déploiements en prod qui ont déjà des pipelines de compaction qui marchent et des queries Iceberg-natives, mais pour les builders qui montent une nouvelle couche analytique en 2026, l'approche catalogue SQL va paraître bien meilleure opérationnellement. Le pitch MotherDuck — « setup prend 2 commandes SQL » — est une description honnête : si t'as déjà un Postgres, t'as un catalogue DuckLake. Le support multi-moteur veut dire que tu ne paries pas sur DuckDB ; tu peux lancer du gros analytique sur Trino pendant que les queries opérationnelles légères tapent DuckDB directement sur les mêmes données. La grande question ouverte, c'est le chemin de migration depuis Iceberg, que l'annonce de lancement laisse vague — c'est le workstream que les 6 prochains mois vont probablement surfacer.

Move pratique : si tu construis une nouvelle couche analytique ou un feature store ML ce trimestre, DuckLake 1.0 mérite une semaine d'eval contre Iceberg. Le gap de simplicité de setup à lui seul est réel — remplace ta config Glue/Hive Metastore par une connection string Postgres. Si tu fais tourner Iceberg en prod avec du tuning de compaction actif, le coût de migration est non-zéro et il n'y a pas de chemin documenté ; revisite quand DuckLake ship des readers/writers Iceberg explicites dans les deux sens. Pour les pipelines ML qui écrivent fréquemment de petits batches (ingestion training-data, logs d'inférence, eval traces), le data inlining seul résout une classe de douleur opérationnelle que les approches basées-compaction continuent juste à payer. La promesse de spec stable 1.0 + l'engagement de backward-compatibility rend ça safe à parier pour les nouveaux builds ; pour les existants, la question, c'est si ta friction actuelle vaut le coût de migration.