DuckLake 1.0 stabilizes its SQL-based lakehouse specification

The DuckDB team released DuckLake 1.0 on April 13, declaring its SQL-based lakehouse specification production-ready and publishing the corresponding extension for DuckDB 1.5.2. The release post describes a stable format with a backward-compatibility commitment.

Metadata stays in a database

DuckLake stores lakehouse metadata in a SQL catalog while data resides in object storage. Its reference implementation supports PostgreSQL, SQLite and DuckDB catalogs. The release includes update and delete inlining, sorted tables and bucket partitioning.

Inlining is particularly relevant to teams feeding a lake a few records at a time: small changes can first live in the catalog rather than immediately creating more data files. That moves an operational question into focus. Engineers should measure catalog growth and flush behavior alongside object counts, rather than evaluating storage costs only after compaction.

A stable format still needs a recovery design

Our analysis is that the catalog deserves the same recovery attention as the data files. A useful rehearsal restores a chosen catalog state and verifies that its referenced objects remain available. Retention and cleanup policies should be tested against that recovery point.

For adoption, pick a table with both frequent small writes and a clear historical query requirement. Measure the time until updates become queryable, the work required to flush and compact them, and the behavior of a second reader during those operations.

The compatibility milestone is a reason to evaluate a longer-lived deployment. It is not evidence that every surrounding connector is interchangeable. Pin the engine, extension and catalog combination, then prove a backup-and-restore cycle before moving the first durable dataset.