DuckDB Labs shipped DuckLake 1.0 last month and MotherDuck wired up production support โ a lakehouse table format that diverges from Iceberg and Delta Lake in one architecturally consequential way: instead of metadata as JSON manifest files in object storage, all metadata and the catalog live in a SQL database. The team's framing of why is direct โ file-based metadata in lake formats leads to complex coordination, slow metadata operations, and many small files. MotherDuck's launch numbers claim 10x faster queries and 10x higher transactions per second on the catalog hot path. Raw data stays in Parquet on object storage; only the catalog moved into Postgres-class durability. License is MIT. Clients ship for Apache DataFusion, Spark, Trino, and Pandas โ multi-engine from day one, not DuckDB-locked.
The mechanism that matters for builders is data inlining. Iceberg's small-file problem is the chronic compaction debt that hits every production lakehouse: stream a few rows, they go to a new Parquet file, repeat ten thousand times, now your reads scan tens of thousands of tiny files until the compaction job catches up. DuckLake's inlining threshold defaults to ten rows โ anything below that hops directly into the SQL catalog instead of spawning a new Parquet object. Sorted tables and bucket partitioning for high-cardinality columns are in 1.0, geometry types got upgraded, and the deletion vectors are explicitly Iceberg-compatible โ meaning a DuckLake-emitted vector reads cleanly from existing Iceberg consumers. The interop is intentional; this is a format trying to win on operational characteristics, not lock-in. The architectural trade is that you've now got a Postgres (or compatible) availability dependency on the metadata path. For most builders that's a feature โ Postgres has been tuned for low-latency high-concurrency reads for forty years. For builders running lakehouses at multi-region without an obvious central catalog DB, it's the new question to design around.
The ecosystem read: the lakehouse-format war between Iceberg and Delta Lake is ten years old at this point and the operational answer hasn't arrived. Iceberg won the metadata-spec battle but Delta still ships better tooling. DuckLake comes in from a third axis โ sidestep the file-based catalog entirely. It won't replace Iceberg in production deployments that already have working compaction pipelines and Iceberg-native queries, but for builders standing up a new analytics layer in 2026, the SQL-catalog approach is going to look much better operationally. The MotherDuck pitch โ "setup takes 2 SQL commands" โ is an honest description: if you already have a Postgres, you have a DuckLake catalog. The multi-engine support means you're not betting on DuckDB; you can run heavy analytics on Trino while light operational queries hit DuckDB directly against the same data. The big open question is migration path from Iceberg, which the launch announcement leaves vague โ that's the workstream the next 6 months will probably surface.
Practical move: if you're building a new analytics or ML feature store this quarter, DuckLake 1.0 is the format worth a one-week eval against Iceberg. The setup-simplicity gap alone is real โ replace your Glue/Hive Metastore configuration with a Postgres connection string. If you're running production Iceberg with active compaction tuning, the migration cost is non-zero and there's no documented path; revisit when DuckLake ships explicit Iceberg readers/writers in both directions. For ML pipelines that write small batches frequently (training-data ingestion, inference logs, eval traces), data inlining alone solves a class of operational pain that compaction-based approaches just keep paying for. The 1.0 stable spec promise + backward-compatibility commitment makes this safe to bet on for new builds; for existing builds, the question is whether your current friction is worth the migration cost.