DAG Explorer

Visualize your entire dbt project as an interactive lineage graph. Understand dependencies at a glance, trace data flow down to the column level, and navigate complex projects with ease.

source

staging

intermediate

mart

Click any node to trace its upstream and downstream lineage

Why Lineage Matters

As dbt projects grow, understanding how models connect becomes critical:

• Impact analysis: Before changing a model, see exactly what downstream models will be affected
• Root cause analysis: When a test fails or data looks wrong, trace back through the chain to find the source
• Onboarding: New team members can quickly understand the project structure and data flow
• Documentation: A living, always-up-to-date map of your data transformations

Interactive Graph

The DAG Explorer renders your project's model dependencies as a fully interactive graph:

Navigation

• Pan and zoom smoothly through projects of any size (tested with 5,000+ nodes)
• Minimap in the corner shows your current viewport within the full graph
• Fit-to-view button centers the entire graph or a selected subgraph
• Fullscreen mode for deep exploration sessions

Node Interaction

Click any node to:

• View the model's description, tags, and configuration
• See the number of rows produced in the last run, along with per-node run status and execution time when a run is loaded
• Jump directly to the model in the IDE for editing

Some nodes, such as generated tests, do not have a file of their own to open. For these, dbdeux shows a clear, friendly notice instead of a broken link, so a missing source file never looks like an error.

Run From the Graph

Models and seeds carry a run button right on the node. Hover a node and pick how much of the lineage to build, using the same selector semantics as dbt:

Option	Selector	Builds
Execute model	model	Just this model
Execute model+	model+	This model and everything downstream of it
Execute +model	+model	This model and everything upstream of it
Execute +model+	+model+	This model plus all parents and children

The run uses your currently selected environment, branch, connection, and dbt version, exactly like the editor run controls, and prompts for confirmation when the target environment is locked.

Filtering and Search

Focus on what matters with powerful filtering:

Filter	Example
By folder	Show only models/staging/
By tag	Show models tagged daily or critical
By resource type	Models, sources, tests, seeds, or snapshots
By materialization	Table, view, incremental, or ephemeral
By schema	Show only models that land in a given schema
By text search	Find any model by name
By run status	Show only failed or errored models
Critical path	Isolate the longest dependency chain in the project

Focus Mode

When a project has hundreds of models, you rarely want to see all of them at once. Pick any model and focus the graph on just its neighborhood: the anchor model plus a chosen number of upstream and downstream hops.

• Adjustable depth: Step the upstream and downstream hop counts up or down independently to widen or narrow the view around the anchor
• Anchor highlight: The model you focused on is ringed so it stays easy to spot inside its subgraph
• One-click clear: Drop back to the full graph whenever you want

You can also jump straight into focus mode from the editor: with a model open, choose Show in DAG and the graph opens focused on that model.

Lineage Highlighting

Select any model to instantly see:

• Upstream dependencies (parents): highlighted in blue, showing everything that feeds into your model
• Downstream dependents (children): highlighted in green, showing everything that depends on your model
• Full path: the complete chain from source to final output

Column-Level Lineage

Go beyond model-level lineage. dbdeux traces data flow at the column level, showing you exactly which input columns contribute to each output column.

How It Works

dbdeux reads your compiled SQL to work out which columns feed which. For every output column in a model, you can see:

• Which upstream columns it derives from
• Through which transformations (joins, aggregations, casts)
• Across how many model layers the data flows

Use Cases

• PII tracking: Follow sensitive columns through your entire pipeline to ensure compliance
• Impact assessment: Know which dashboards and reports break if you rename or remove a column
• Data quality: When a metric looks wrong, trace the specific columns involved back to the source
• Audit and compliance: Prove data provenance for regulatory requirements

To see it as a picture, open the column graph: each model becomes a card of its columns with an edge from every column to the columns built from it. Click a column to trace it, and widen the upstream or downstream hops to follow it further. The full walkthrough is in Atlas Catalog, The Column Graph.

DAG Panel in the Editor

The DAG Explorer also appears as a collapsible panel in the bottom section of the IDE, alongside the Output and Compiled SQL tabs.

Minimize to Rail

Click the collapse button to shrink the DAG panel down to a thin rail at the bottom of the editor. This gives you the full editor height while keeping the DAG one click away. Click the rail to expand it back to full height.

Detail Pane

When you click a node in the DAG panel, a detail pane shows:

• Model name, resource type, and tags
• Upstream and downstream dependency counts
• A quick link to open the model file in the editor

Column Graph in the Editor

Select a model in the editor's DAG panel and click Show column graph to draw the model and its neighbors as cards of columns, the same view as in the catalog. Back to model view returns to the normal graph. The editor works out the lineage from the files in your branch, so you see the effect of a change before you build it.

Some SQL cannot be fully worked out from files alone, for example SELECT *, macro-generated columns, or upstream models whose columns are not declared in their schema .yml. When that happens, the panel fills the gaps for you instead of showing a half-empty graph:

1. It first uses what the editor could work out from your branch.
2. It then checks the Data Catalog, which holds the compiled SQL of your last build.
3. If the model is not there yet, it checks the last Slimmer CI run on your branch.

The panel says which source each edge came from and how exact it is, for example Exact: every input column resolved or Partial: some columns come from macros the editor could not expand. When none of the sources can help, it tells you why in plain words (the model has never been built, the last CI run did not include it, or its SQL is not supported) and what to do next: declare the upstream columns in schema .yml, run dbt compile or dbt build, or open a pull request and let Slimmer CI run. Lineage from a build always reflects that build, not edits you have not built yet, and the panel says so.

Only models inside the current hop window are traced; other cards show the columns declared in their schema .yml. Widen the hops to trace further.

Calculated Columns and Macros

A column does not need to be a plain copy to be traced. Columns built with CASE, arithmetic, casts, or functions link to every column they use, so margin_bucket built from case when margin_pct >= 0.4 ... links back to margin_pct.

Editor · DAG panel · dim_productdim_product builds margin_bucket with a CASE on margin_pct, and sk with a package macro

select
  product_id as product_key,
  case when margin_pct >= 0.4 then 'high'
       when margin_pct >= 0.2 then 'medium'
       else 'low' end as margin_bucket,
  {{ dbt_utils.generate_surrogate_key(['product_id']) }} as sk,
  product_name
from {{ ref('int_product_hierarchy') }}

Show column graphOpen in Atlas Catalog

Some Jinja cannot be worked out inside the editor, for example a macro from an installed package such as dbt_utils.generate_surrogate_key. The editor now skips only that call and keeps tracing every other column in the model. The card and the panel name the call it could not evaluate, so you know exactly which columns are missing a link and why. dbt_utils.star is read as "every column of that model", so those columns still trace.

When the editor's own reading is partial, the panel fills every card in the window from your last build, not just the model you selected, so neighboring models show their columns too.

Open in Atlas Catalog

For large areas, click Open in Atlas Catalog under Show column graph. The Atlas Catalog opens the same model, with the same upstream and downstream hops, straight into its full-width column graph. The catalog reads the compiled SQL of your last build, where every macro is already expanded, so it is also the place to see columns the editor could not trace.

Live and Server Graphs

The panel can build the graph two ways, and you can switch between them at any time:

• Live (working tree): builds the graph from the exact files in your current branch, so uncommitted edits and new models show up immediately
• Server graph: uses the pre-indexed project graph for fast, lightweight rendering

For very large projects, dbdeux automatically uses the server graph to keep the editor responsive and lets you know it did. You can always pin Live (working tree) to force a full build from your working files. If the working tree cannot be read for any reason, the graph falls back to the server version automatically so you always see lineage rather than an empty panel.

The server graph is built from your project's ingested dbt manifest. If a project does not have one yet, the panel shows a Generate server graph button so you can build it on demand, with a retry option if the build does not succeed the first time.

Performance

The graph renders instantly even for large projects:

• Server-side pre-computation means zero client-side processing delay
• Automatic fallback to the server graph on very large projects keeps the editor responsive
• Smooth pan and zoom interactions at any project size
• A layered layout keeps lineage readable and prevents visual clutter