DuckDB Labs 上个月 ship 了 DuckLake 1.0，MotherDuck 接好了生产支持 — 一个 lakehouse 表格式，与 Iceberg 和 Delta Lake 在一个架构后果性的方面分歧：元数据不再是 object storage 上的 JSON 清单文件，而是所有元数据和目录都活在一个 SQL 数据库里。团队对为什么的 framing 直接 — file-based 元数据在 lake 格式里导致复杂的协调、慢的元数据操作、和很多小文件。MotherDuck 的发布数字声称在目录热路径上 10x 更快的 queries 和 10x 更高的每秒事务。原始数据仍在 object storage 的 Parquet 里；只有目录搬到了 Postgres 级耐久性。许可 MIT。客户端 ship 了 Apache DataFusion、Spark、Trino 和 Pandas — 第一天就是多引擎，不锁 DuckDB。
对 builder 重要的机制是 data inlining。Iceberg 的小文件问题是每个生产 lakehouse 都中招的慢性 compaction 债：stream 几行，进一个新 Parquet 文件，重复一万次，现在你的 read 扫几万个小文件直到 compaction job 追上。DuckLake 的 inlining 默认阈值是十行 — 低于这个直接跳进 SQL 目录而不是生成新 Parquet 对象。1.0 里有 sorted tables 和高基数列的 bucket partitioning、geometry 类型升级了、deletion vectors 显式与 Iceberg 兼容 — DuckLake 发出的 vector 在现有 Iceberg consumer 上能干净地读。互操作是刻意的；这是一个想在运维特征而非 lock-in 上赢的格式。架构 tradeoff 是你现在在元数据路径上有了 Postgres（或兼容）可用性依赖。对大多数 builder 是 feature — Postgres 被为低延迟高并发读 tune 了四十年。对没有明显中央目录 DB 的 multi-region lakehouse builder，这是要绕着设计的新问题。
生态读法：Iceberg 和 Delta Lake 之间的 lakehouse 格式战争到这地步已经十年了，运维上的答案没出来。Iceberg 赢了元数据 spec 战争，但 Delta 还是 ship 更好的工具。DuckLake 从第三个轴进来 — 完全绕过 file-based 目录。它不会替换那些已经有可用 compaction 管线和 Iceberg-native 查询的生产 deploy 中的 Iceberg，但对 2026 年立起新分析层的 builder，SQL 目录方法在运维上会看起来好得多。MotherDuck 的 pitch — 「setup 两条 SQL 命令」 — 是诚实描述：如果你已经有 Postgres，你就有 DuckLake 目录。多引擎支持意味着你不押注 DuckDB；你可以在 Trino 上跑重分析，同时轻量运维查询直接打 DuckDB 同样的数据。大的开放问题是从 Iceberg 迁移的路径，发布公告留得很模糊 — 这是接下来 6 个月可能浮现的 workstream。
实际动作：如果你这个季度在搭一个新的分析层或 ML feature store，DuckLake 1.0 值得花一周对比 Iceberg eval。setup 简化的差距本身就是真的 — 把你的 Glue/Hive Metastore 配置换成 Postgres connection string。如果你跑生产 Iceberg 还在调 compaction，迁移成本非零而且没有文档路径；当 DuckLake ship 双向显式 Iceberg readers/writers 时再回来看。对频繁写小批次的 ML 管线（training-data 摄入、推理日志、eval traces），data inlining 一项就解决了基于 compaction 的方法一直在交学费的一类运维痛苦。1.0 稳定 spec 承诺 + 向后兼容承诺让这对新 build 安全可押；对现有 build，问题是你当前的摩擦值不值得迁移成本。