datafusion-ducklake

The main reason was due to a much easier tight-integration with the DuckDB internals, so we can take the most of the DuckDB engine (and existing code) to use. As the extension must interact with table scanners, casting functions and whatnot. However, DuckLake doesn't need to be implemented in C++ at all, I believe that whatever fits the engine that will be performing the reads/writes in Parquet and the connectors for the DBMSs should be a good fit. For example https://github.com/borchero/ducklake-sdk - Rust https://github.com/datafusion-contrib/datafusion-ducklake - Rust https://github.com/motherduckdb/ducklake-spark - Scala https://github.com/brikk/trino-ducklake - Kotlin Disclaimer: I'm the lead developer of DuckLake.

Don't think it's widely known or understood, but Ducklake doesn't require duckdb: it's just a (good) data lake spec that works in duckdb. There's a cool alternate rust/datafusion ecosystem initiative going on at https://github.com/datafusion-contrib/datafusion-ducklake, and think the Quack protocol opens up a lot of cool possibilities too. If you need an idea for what do do with ducklake: recommend throwing all of your agent traces in it.

https://github.com/datafusion-contrib/datafusion-ducklake is more established, and linked to directly from the ducklake docs