A Frozen DuckLake needs someone to retain its files

A read-only catalog can remove a database server from an archive’s serving path. The archive still depends on the objects that catalog references. Frozen DuckLake is attractive when readers need a published dataset and one controlled process can prepare it. Its operating contract should cover catalog versions and data-file retention together, with someone responsible for both.

The distinction matters when “serverless” becomes shorthand for work nobody owns. A catalog that opens successfully can still point to an unavailable file. A retained catalog version can outlive the access policy or storage lifecycle that made its data readable. Removing a running catalog service changes the shape of maintenance; it does not eliminate the decisions that preserve a useful archive.

The published file is a catalog

In Mark Harrison’s guest post of 24 October 2025, the design publishes a local DuckDB-format DuckLake catalog to cloud storage while data remains in referenced Parquet files. Readers access the published catalog in read-only mode. The source describes a single-writer, multiple-reader archive and data files that are neither modified nor moved after writing. Those deployment experiences belong to Harrison, not AL+.

The mechanism creates a useful separation between preparing the archive and serving its published form. Readers do not need to coordinate writes to that read-only copy. The publisher still decides what becomes visible and when. Treat this as a publication workflow: a prepared artifact represents a selected dataset, while the storage references define the data needed to query it.

A catalog copy is therefore not automatically a complete backup of the dataset. Whether it is sufficient for recovery depends on the referenced objects and their continued availability. Before accepting an archive handover, identify which files are actually contained in the artifact and which are dependencies elsewhere. A concise dependency list is more useful than an unsupported assurance that the database is “all in one file”.

Version publication is an operating decision

Give readers a stable way to identify the catalog version they used. A versioned location can make an analysis reproducible if the corresponding data stays unchanged and available. A moving “latest” location serves a different purpose: it helps readers find the newest publication but cannot alone identify the state behind an older result. Choose those interfaces deliberately.

Publish only after the catalog and its referenced data are ready for the intended readers. Decide how a reader discovers a complete version, how a failed publication is recognised and how the previous version remains usable. These are recommended publication requirements, not guarantees supplied by a particular object store in this article. The actual storage system’s behaviour must inform the implementation.

The source describes manual catalog schema upgrades for read-only published files and suggests retaining a separately named original for older clients. It also says that data schema migration is outside the post’s scope. Keep catalog format compatibility distinct from changes to the dataset’s tables and meaning. The article is a design reference, not a complete migration procedure for every archive.

Retention follows references across versions

A deletion decision should consider every catalog version the organisation still promises to serve. A data object absent from the newest publication may still be needed by an older one. Deleting it because it is no longer current can break the older archive while leaving the older catalog intact. The useful unit of retention is the published version and its reachable data, not just the catalog filename.

This yields a practical ownership rule: whoever changes storage lifecycle settings should know which publications remain supported. If those duties belong to different people, give them a shared retention record. It should be possible to answer whether an object is still needed before removing it. A storage-age rule alone cannot express that relationship unless the publication process was designed around it.

Access must follow the same reasoning. Retaining an object does not help a reader whose permissions have expired or whose client cannot reach its location. Define the intended audience and the access arrangement for both catalog and data. A publicly readable catalog does not itself grant permission to a private object, and publishing metadata should be reviewed for the information it exposes.

The current stable maintenance reference, labelled 1.1 when consulted, separately describes expiring snapshots and cleaning up old files. This is current documentation, not evidence of the 2025 implementation. A publication policy must account for supported frozen copies before applying cleanup to shared objects.

Rebuilding needs repeatable inputs

The 2025 post warns that adding the same file repeatedly with ducklake_add_data_files() duplicates data. Treat that as a limitation of the workflow described there, rather than silently assuming later behaviour. A publisher needs a reliable account of which files have been included and how their paths are represented. Apparent differences in path strings should not become accidental duplicate inclusion.

A publication check should ask whether the intended tables can be queried by an intended reader and whether the catalog references the intended object set. Check a retained older publication as well when promising historical access. These are proposed checks; no DuckLake deployment or data benchmark was run for this article. The guest post’s performance experience cannot establish the speed or cost of another dataset.

Restoration also needs an explicit target. Restoring the newest catalog answers a different requirement from reproducing a report made with an older version. Decide which requirement the archive serves before choosing retention length. Otherwise the team may preserve enough data for current queries while losing the precise state needed to explain an earlier decision.

Some workloads need a live catalog

The strongest counterargument is concurrent change. When many users need coordinated writes or readers require immediate updates, a periodic frozen publication can introduce the wrong freshness and coordination model. A live multi-user catalog may justify its operating cost. Do not select the frozen design solely to remove a server from an architecture diagram.

The design is easier to justify for controlled publications whose readers can accept a defined update cadence. Even there, someone must own compatibility checks, publication failures and the storage bill. For software maintenance, put those responsibilities beside object retention in the scope. The useful handover is a catalog version readers can identify, files they can still read and a named person who decides when that promise ends.