An unmodified dbt project now runs as a Windmill script. Copy the project into a <script>__dbt/ folder, wmill sync push, and Windmill runs dbt build on your own workers with live per-model progress, per-model results, dbt retry and row previews. Since v1.777.0, dbt is in the new-script language picker and opens in an editor of its own - the project's file tree, its descriptor, the run form and a model graph that Refresh models redraws from a dbt parse of the files as they are in the editor, labelled with where it came from. Its models, sources, seeds and snapshots become dbt://warehouse/schema/model assets with their ref() lineage, so a Python or DuckDB script reading a mart appears on the same graph. Warehouses are configured once per workspace and named from the optional wm_dbt.yaml descriptor, so the project carries no connection and stays runnable locally. Three engines are selectable (dbt Core 1.x by default, dbt Core 2.x, dbt Fusion), all fetched or built on first use and cached per worker. Everything is in the community edition except the mssql and oracle adapters.

Workspace forks now get an isolated data environment per DuckLake by default. Materializing pipelines in a fork write to a fork-scoped metadata schema and bucket prefix instead of the parent's tables, and tables the fork has not materialized yet are read from the parent through read-only defer views, so one node can be iterated on without rebuilding upstream. The fork-creation dialog adds a per-lake Isolated / Shared with parent choice, the pipeline graph shows deferred vs fork chips on DuckLake assets, and deleting a fork can drop its forked namespaces.

Consumer scripts referencing materialized DuckLake tables are now validated against the captured producer schemas at save time. Missing columns, dropped lineage sources and mismatched relationship types surface as warnings (never errors) after deploy, as live editor squiggles, and column names autocomplete with their types when typing . after a ducklake:// reference on annotation lines. Producers can declare a deliberately unstable schema with on_schema_change=ignore on the // materialize line to collapse downstream warnings into a single note.

The // freshness <window> annotation on pipeline scripts now shows a live fresh/stale verdict on the pipeline graph, emerald when the last successful run completed within the window and amber when it is stale or has never run. On Enterprise Edition, a freshness watchdog re-runs stale unpartitioned scripts automatically with exponential backoff capped at the window; watchdog runs skip the downstream cascade, are attributed to pseudo-user freshness- with the new freshness trigger kind, and can be disabled instance-wide with DISABLE_FRESHNESS_WATCHDOG.

Ducklakes can now run scheduled maintenance to keep growth in check - snapshot expiry with a configurable retention window (default 7 days), compaction of adjacent small parquet files, and orphaned file cleanup. Configured per lake in the workspace Ducklake settings with a cron cadence (default daily at 03h UTC) and executed as observable jobs whose run history is the audit trail. Enterprise feature.

Share SQL logic across a workspace with macro libraries. A DuckDB script annotated // macros publishes engine-native CREATE MACRO definitions on deploy; any DuckDB script that calls a registered macro gets the definitions injected at run time, with no import or compile step. Includes editor autocomplete, a workspace macros explorer, and library nodes in the pipeline graph.

On a partitioned DuckLake asset, the Backfill button opens a range picker that previews which partitions are missing, failed or materialized, then re-runs the producing script once per partition with an explicit partition argument. Runs are sequential and idempotent, a failed partition does not stop the rest, and progress streams in the dialog and drawer header. Range backfill is an Enterprise feature; single-partition runs stay available in all editions.

Edit, preview and run data pipelines from local files without deploying. wmill pipeline show/run --local builds the graph from your working tree with the same parser the UI uses, wmill pipeline dev live-previews the graph in the browser on every save, and wmill pipeline docs writes a PIPELINE.md for coding agents.

New managed history strategy on // materialize keeps every version of every row (slowly changing dimension type 2). A change closes the prior version and opens a new one, with managed valid_from/valid_to/is_current columns, an auto-maintained <table>_current view, and support for effective-dated ASOF joins. Data tests and schema capture keep working, unlike hand-written materialize manual SQL.

Connect scripts into a pipeline through the assets they read and write, with comment annotations for schedules, time and dynamic partitions, AND/OR joins, opt-in debounce, managed DuckLake materialization, column-level lineage and data tests. Pipelines are in alpha; the annotation syntax and behavior may still change.