Dagster 1.13.11 - Virtualized Asset Catalog and Insights Metadata
Dagster 1.13.11 was published on June 25, 2026, as the core release paired with library version 0.29.11. The main user facing change is in the asset catalog, where the UI now renders a single virtualized list so large workspaces do not stall when users expand many asset groups or code locations. For operators, the release also tightens asset check history cleanup and adds better selection counts for GraphQL clients.
The full release notes and downloads are on the GitHub release page.
Asset catalog scaling in the UI
The most visible change in Dagster 1.13.11 is the asset catalog rewrite to render as one virtualized list. That matters when a workspace has many asset groups or many code locations. Before this release, expanding those sections could freeze the browser UI. The notes say the new behavior should avoid that freeze when those sections open.
This is a practical fix for Dagster users with larger deployments. Asset catalogs tend to grow slowly, then suddenly become painful after enough teams and jobs land in the same workspace. Virtualized rendering keeps the browser focused on the visible rows instead of paying the cost for everything at once.
The run detail page also gets a smaller but useful UI correction. For asset job runs, the header now shows the asset check count. More important, the count comes from the execution plan instead of a scan through the full run event log. That should make the number cheaper to show on busy runs, and it avoids another place where large histories can make the UI feel heavier than it needs to be.
Dagster+ Insights metadata from dagster-dbt
The dagster-dbt change is small in syntax but useful for teams managing config in YAML. DbtProjectComponent now accepts an "insights" option in its include_metadata field. That enables Dagster+ Insights tracking from YAML config, rather than needing a separate code path for that metadata choice.
There is also a better failure mode around .with_insights(). When it is called with an unsupported adapter, Dagster now logs a warning instead of raising. That is the sort of change operators notice during rollout. A warning still tells you the adapter is not supported, but it does not break the whole path just because Insights metadata could not be attached.
The documentation update for the “Run concurrency” Insights metric fits the same theme. It gives teams a clearer reference for what the metric means when they are reading Insights data, instead of forcing interpretation from dashboard labels alone.
GraphQL selection counts for run clients
Dagster 1.13.11 adds an optional limit argument to the Run GraphQL type, plus assetSelectionCount and assetCheckSelectionCount fields. This gives API clients two pieces of information at the same time: a bounded preview of selected assets or checks, and the real total count.
That distinction is useful for UI and automation clients. A client can render a short preview without pulling a huge selection payload, while still showing the true size of the run selection. For large asset graphs, this is the difference between a page that gives enough context and a page that tries to fetch too much.
The release notes do not present this as a breaking GraphQL change. It is an additive change, so existing clients can ignore it until they need bounded previews or better counts.
Asset check cleanup and lineage fixes
The asset check history fix is worth calling out for anyone who wipes assets or partitions. After this release, asset check history is cleared when an asset or its partitions are wiped. Old entries should no longer remain in the Execution History and Partitions views.
Stale check history is not glamorous, but it creates real confusion. If a user wipes state and still sees old check results, the UI starts telling two stories. This release aligns the visible history with the wipe action.
The run actions menu also gets a bug fix. “View asset lineage” now scopes correctly to the assets in that run. That is a narrow fix, but a useful one when lineage navigation is part of incident review or day to day debugging.
Documentation fixes for deploy checks
The documentation changes are mostly operator focused. Dagster now has a page for Dagster+ code location snapshot size limits. The notes mention a local script that can estimate snapshot sizes before deployment.
That is the right kind of documentation for a platform limit. It gives teams a way to check risk before a deploy fails, instead of learning only after the deploy path is already blocked.
The release also fixes an invalid pool config in the “Preventing concurrent dbt snapshots” DbtProjectComponent example. This is a small doc correction, but examples get copied. Invalid config in an example wastes time, especially when the reader is already trying to solve a concurrency problem.
Where to get it
- Release page: GitHub release page
- Repository: project repository
- Tag:
1.13.11