Dagster 1.13.11 - Asset Catalog And dbt Insights

Dagster 1.13.11 was published on June 25, 2026, as a core release for Dagster with library release 0.29.11. The main operator visible change is the asset catalog moving to a single virtualized list, which should reduce browser stalls in large workspaces with many asset groups or code locations. The release is not marked as a prerelease.

The full release notes and downloads are on the GitHub release page.

The asset catalog change is practical for teams that let Dagster workspaces grow by domain, code location, and asset group. Before this release, expanding many groups could freeze the UI. In 1.13.11, the page renders as a single virtualized list, so the browser handles the visible portion of the catalog instead of trying to carry too much state at once.

For data platform owners, this is less about polish and more about response time during incident review. When a failed materialization or stale partition has to be traced, the catalog is one of the first screens people open. A virtualized list does not change run semantics, but it reduces the chance that a large workspace makes the control plane feel dead.

This does not remove the need to prune old code locations or keep asset definitions sane. It only moves a known rendering path away from a browser workload that scales poorly.

dagster-dbt adds "insights" as an option for the DbtProjectComponent include_metadata field. That matters for teams that keep dbt wiring in YAML and want Dagster+ Insights tracking without adding a custom Python branch. It also makes config review easier because the metadata inclusion choice sits beside the rest of the component config.

The related .with_insights() bug fix is a safer failure mode. On unsupported adapters, it now logs a warning instead of raising. A rollout across mixed dbt adapters should fail less abruptly, while still leaving a signal in logs that Insights tracking did not attach.

This is still adapter dependent. The release notes do not claim new adapter coverage. Treat the warning as a guardrail, not proof that every dbt project is now instrumented.

dagster-graphql adds an optional limit argument and new assetSelectionCount and assetCheckSelectionCount fields to the Run GraphQL type. Clients can render a bounded preview of a run asset and check selection while still showing true totals. That is useful when a run touches enough assets that unbounded selection data becomes a poor API shape for UI clients.

The practical point is simple. Show a limited list, show the real count, and avoid loading all selected assets just to draw a header or preview. For platform operators, that makes run views more predictable on larger graphs without changing the selection itself.

The run detail page also now displays the asset check count for asset job runs. More important, the count is read from the execution plan rather than by scanning the full run event log. That is the right direction for large runs, where event log scans turn a simple count into unnecessary IO.

Bug fixes also cover stale asset check history. When an asset or its partitions are wiped, asset check history is now cleared. That keeps Execution History and Partitions views from showing stale entries after data has been intentionally removed.

The “View asset lineage” action is now scoped to assets in the run. That should reduce confusing lineage jumps when a run only covers part of a larger graph.

Documentation changes are worth noting because they touch deploy checks and concurrency. Dagster added a page for Dagster+ code location snapshot size limits, including a local script for estimating snapshot sizes before deployment. The release also documents the “Run concurrency” Insights metric and fixes an invalid pool config in the “Preventing concurrent dbt snapshots” DbtProjectComponent example.