DuckLake extends DuckDB with a lakehouse architecture that separates metadata and data. According to the project’s README, DuckLake stores metadata in a catalog database and keeps the actual data in Parquet files. This design lets DuckDB directly read and write data managed by DuckLake using standard SQL commands after attaching the lake with an ATTACH statement. The README shows an example where metadata is kept in a DuckDB file called metadata.ducklake and the data lives in Parquet files under a file_path directory, accessed via ATTACH 'ducklake:metadata.ducklake' AS my_ducklake (DATA_PATH 'file_path/').
The logo identifies the DuckLake project, which is the subject of the article describing its lakehouse architecture and features.
The extension supports several advanced data‑lake features illustrated in the usage guide. Users can create tables, insert rows, and run queries just as with any DuckDB schema. Time travel is available through queries like FROM my_ducklake.my_table AT (VERSION => 2); which returns the table as it existed at a specific version. Schema evolution is handled with ALTER TABLE statements that add columns, and the change data feed can be accessed via table_changes functions to inspect snapshots, row IDs, change types, and the modified data. These capabilities are demonstrated with concrete SQL snippets in the repository’s documentation, including INSERT, UPDATE, and SELECT statements that show how data and metadata evolve.
Installation is straightforward: the extension can be added with the command INSTALL ducklake; and the latest development version is obtainable from the core_nightly channel via FORCE INSTALL ducklake FROM core_nightly;. Building from source requires initializing git submodules, updating them recursively, and compiling with make GEN=ninja release. After building, the bundled DuckDB binary can be run via ./build/release/duckdb. The project also provides a suite of test commands for validating the extension under various configurations, such as running all tests with ./build/release/test/unittest, running a single test file, running tests matching a pattern, running DuckDB core tests using DuckLake as storage backend, running DuckLake tests using PostgreSQL or SQLite as the catalog database, and running tests with deletion vectors enabled.