DuckLake 0.3 ships with the ducklake DuckDB extension (requiring DuckDB v1.4.0), adding shallow-copy interoperability with Apache Iceberg (deep and metadata-only copies, plus querying historical Iceberg snapshots as DuckLake tables), MERGE INTO support for upserts and conditional deletes, a new CHECKPOINT statement for maintenance tasks, a per_thread_output option that improved insert speed by ~25% in benchmarks, experimental geometry type support via the spatial extension, and author-commit metadata for audit trails. Existing DuckLake catalogs auto-migrate from v0.2 to v0.3 metadata schema when attached with the new extension.
Questions this post answers
How do I copy data between Iceberg and DuckLake tables using DuckDB?
DuckDB's iceberg extension combined with the ducklake extension (DuckDB v1.4.0+) supports shallow-copy operations between the two formats using COPY FROM DATABASE, after attaching both an iceberg catalog and a ducklake database. Deep copies transfer the latest snapshot's data, while iceberg_to_ducklake() performs metadata-only copies that preserve full snapshot history, letting you query previous Iceberg table versions through DuckLake's AT (VERSION => n) syntax. daily.dev surfaces practical release notes like this for teams wiring Iceberg and DuckLake into the same pipeline.
Does DuckLake support MERGE INTO for upserts?
Yes, as of DuckLake 0.3 the ducklake DuckDB extension supports MERGE INTO, since DuckDB 1.4 added the statement. It handles WHEN MATCHED THEN UPDATE, WHEN NOT MATCHED THEN INSERT, and conditional DELETE clauses, making it useful for OLAP-style upsert workflows in systems without primary key constraints. Following upsert and merge semantics across database engines gets easier when release details land on daily.dev.
How much faster are inserts in DuckLake with the per_thread_output option enabled?
Enabling per_thread_output produced roughly a 25% improvement in a benchmark inserting one billion rows, dropping copy time from 4.5 seconds to 3.4 seconds. The option is most beneficial when each thread's output is reasonably large, such as running DuckDB on an EC2 instance with high network bandwidth to S3; with many threads and small per-thread output it can instead create too many small files and hurt read performance. Benchmarks like this help engineers tuning DuckLake write performance decide when daily.dev-tracked options are worth enabling.