DuckLake 1.1 was released in October 2026 alongside DuckDB 2.0.0 LTS, The New Stack reported, with a design that keeps lakehouse table metadata in a standard SQL database rather than in manifest files on object storage. For data teams using Parquet-based lakes, that design moves table versioning and file lookup into a relational catalog.
Metadata as a database problem
DuckLake is an open-source table lakehouse format created by Amsterdam-based DuckLabs. Pedro Holanda, lead DuckLake developer and principal engineer at DuckLabs, described the rationale as avoiding migrations when organisations exchange database systems. His point was that table formats need a reliable way to know which version of a table is current and which data files belong to it.
In DuckLake, a server answers metadata queries and returns the Parquet files that a query needs to read. The Parquet files remain the data layer while the catalog changes. This treats lakehouse metadata as a SQL schema and transaction problem, rather than as a set of manifest files spread across object storage.
File maintenance and streaming workloads
The 1.1 release pairs new features with more than 200 bug fixes for quality and stability, and it runs natively in DuckDB. Maintainers can combine many files into one to reduce object storage requests, including across snapshots. DuckLake also addresses the small files problem in streaming data lakes and lakehouses by using inlining and flushing.
Inlining stores the data representation as a table in the catalog. The stated aim is to reduce the number of files a query has to inspect and read. That matters where multiple data sources insert at the same time and a lakehouse has to traverse metadata before it can identify the Parquet files for a query.
Part of the fit with DuckDB comes from the storage formats. Parquet and DuckDB storage are both columnar and organised in row groups, which reduces conversion work between them. DuckLake uses that alignment while keeping the table catalog in SQL.
Release and tooling implications
DuckLake and DuckDB remain free and open source under the MIT licence, overseen by the independent DuckDB Foundation. Early adopters of 1.1-dev1 catalogs need to migrate to 1.1, as the release replaces that development format. The GitHub release page for duckdb/ducklake did not list packaged releases at the time reflected in the supplied material.
Adjacent tooling has also added DuckLake support. The dbt-duckdb 1.10.0 and 1.11.0 release notes list DuckLake connection instructions, managed DuckLake support, partition and sorted alter flows, partition functions and transactions for DuckLake tables. That does not remove migration work for existing projects, but it shows the format appearing in the tools data teams already use.
AWS has also put DuckDB and DuckLabs in a wider analytics context. During Amazon’s Q3 earnings call in late October, CEO Andy Jassy linked Amazon’s DuckLabs acquisition to reducing the work of moving data between stores and analytics engines. He said customers would be able to write SQL queries once and execute them using AWS analytics services, and that query portability could also help agents query data more efficiently.
For platform teams, the practical question is whether SQL-held metadata reduces object-store traversal and file maintenance in their own workloads. DuckLake changes where the lakehouse keeps its control plane, but the operational test remains query behaviour, catalog migration and tool compatibility. Teams already standardising on Parquet and DuckDB have the clearest path to evaluation.
Deciding whether lakehouse metadata should live in object storage manifests or a SQL catalog affects query planning, maintenance work and AI data access, which ECS's Data topic examines alongside Microsoft Fabric, Power BI, SQL Server and Dataverse. Sessions and workshops give attendees room to compare platform choices, modelling patterns and operational lessons from practitioners. Bring the lakehouse designs and migration questions that are difficult to settle from release notes alone.
This article was written by the ECS editorial team with the assistance of Amal Agent, run.events' AI assistant, which supported the research, drafting and proofreading.