dbt Projects on Snowflake: Column-Level Lineage, Expanded DAG, and the Fusion Engine

Last updated: May 2026

Why This Update Matters

Anyone who has worked on a real production dbt project knows that the standard dbt docs graph stops being useful around the 150th model. You can see boxes and arrows, but not which columns flow where. If a finance analyst asks "where does net_revenue in fct_orders come from?", you usually end up grepping CTEs.

Snowflake's May 19, 2026 update for dbt Projects on Snowflake closes that gap natively, inside Snowsight. The lineage view now expands every model node so each individual column is visible, and clicking a column highlights every upstream and downstream model that participates in producing or consuming it. There is no external catalog product to install. It runs on the Horizon Catalog that already sits underneath your warehouse.

What Shipped on May 19, 2026

1. Column-level lineage across three surfaces

The same column-aware DAG view now appears in:

• Workspaces — the in-Snowsight dbt development environment.
• dbt project object details — the new "look at this dbt project" page in Snowsight.
• Query History — per-query lineage view, useful for debugging "why did this query touch that column".

Each model node displays its columns, powered by the Horizon Catalog. Selecting a column highlights all connected upstream and downstream models.

2. In-DAG search

A search bar inside the DAG lets you jump to a model by name. For projects with hundreds of models that previously required visual hunting, this is the single most useful addition.

3. Expandable upstream and downstream depth controls

You can dial how many hops to render in each direction. This avoids the "fully expanded DAG is a hairball" problem. Start at depth 1 in both directions, expand as you need to chase a column.

4. Unified side panel

Click any model and the right-hand pane now shows: row count, column count, compiled SQL, and runtime information. Everything you previously needed to bounce between three tabs for is in one place.

5. Increased model display limit: 100 to 300

The previous cap of 100 models on the canvas was uncomfortably small for any mature project. The new limit of 300 covers the great majority of real-world dbt repos in one view.

6. dbt Fusion engine

The bigger architectural piece in this release: dbt Projects on Snowflake now supports the dbt Fusion engine, described in the release notes as "a ground-up rewrite of the dbt runtime in Rust" designed to deliver improved compilation times as project complexity increases. No additional licensing is required, and there are no user limits.

7. Multi-version dbt support via DBT_VERSION

You can now pin a specific dbt version to a dbt project object at creation time using the DBT_VERSION parameter, or override it at runtime. The supported versions at this release are dbt Core 1.9.4, dbt Core 1.10.15, and dbt Fusion 2.0.0-preview. An account-level default is configurable via DEFAULT_DBT_VERSION.

Walking Through the New Column-Level Lineage View

Pretend you have a typical retail dbt project: stg_orders → int_order_items → fct_orders, with fct_orders.net_revenue as a calculated field. Before this update, the DAG would show three boxes connected by arrows. After this update:

1. Open the project object detail page in Snowsight (or open the DAG inside your Workspace).
2. Locate fct_orders. Each node now lists its columns inside the box.
3. Click the net_revenue column. Every upstream column it depends on lights up: typically gross_revenue in int_order_items and discount_total in stg_orders, then those propagate further upstream.
4. Click any of those upstream columns to walk one more hop back, or use the depth control to expand the whole chain at once.
5. The right-hand panel shows the compiled SQL for the selected node so you can see the actual formula without leaving the page.

This is the workflow data analysts and analytics engineers have been doing manually for years. Native, free, and pulled from authoritative warehouse metadata.

Pinning Your dbt Version

Multi-version support is a quietly important feature for teams that cannot move every project to the newest dbt at once. Snowflake's release notes call out three knobs:

• Account default: DEFAULT_DBT_VERSION. New projects created without an explicit version use this.
• Per-project pin: set DBT_VERSION when you create the dbt project object.
• Per-run override: supply DBT_VERSION at runtime.

Recommended practice: pin every existing project to its current runtime explicitly so an account-level upgrade does not surprise anyone. Roll forward one project at a time after smoke-testing on a staging environment.

When to Move to Fusion

dbt Fusion is the Rust rewrite, available as dbt Fusion 2.0.0-preview on Snowflake. It is preview, not GA, on this surface, so plan accordingly. Reasonable adoption order:

1. Inventory: run a one-time compile pass on each project and capture the timings.
2. Pilot: pick one project that has long compile times (typically anything with hundreds of models and heavy ref() chains) and pin it to Fusion in a clone of your dev environment.
3. Compare: measure compile and run times under Core vs Fusion. Watch for any Jinja or macro behavior that differs.
4. Promote: if numbers look good and there are no regressions, switch the project to Fusion in dev, then UAT, then prod. Keep Core pinned on everything else until Fusion goes GA.

Because the runtime is preview, do not roll the whole shop to Fusion at once. Move one project at a time.

How This Replaces Common Third-Party Tooling

If you have been using a standalone data catalog or lineage tool primarily for column-level lineage on dbt models, this update changes the cost-benefit. The native view does not have every feature of a dedicated catalog (no glossary, no business-domain ownership, no usage analytics), but for the basic "where does this column come from?" workflow, it removes the need for a separate license and a separate UI.

For teams that bought a third-party catalog primarily because dbt's built-in docs ran out at the column level, this update is a strong reason to revisit the contract at renewal time.

Operational Tips for the New DAG

• Default to low depth, expand on demand. Start the DAG view at upstream depth 1, downstream depth 1. Add hops only when you need them. The hairball is not your friend.
• Annotate your dbt models with descriptions. The side panel shows compiled SQL; descriptions are still where business context lives. Spend an afternoon backfilling them for your top 20 mart models.
• Use the search bar instead of pan-zoom. Old muscle memory wants to pan around to find a model. The search bar is faster on any project bigger than a screenful.
• Confirm row and column counts. A row count of zero or a sudden drop in column count is often the first visible symptom of a broken upstream model. The side panel makes this easy to spot.
• Combine with our governance guide. Lineage is more useful when masking policies, RLS, and ownership are also defined.

Where This Update Fits in the Broader Snowflake AI/Analytics Story

This release is part of a clear pattern: more of the data engineering toolchain is moving inside Snowflake's surface area, with the Horizon Catalog as the consistent metadata backplane. Native column-level lineage joins:

• Recently shipped Cortex AI Guardrails for prompt injection protection.
• The new Batch Cortex Search table function for high-throughput fuzzy matching.
• Earlier 2026 work on Cortex Code, Snowflake Intelligence, and the wider Cortex Agents surface area.

The implication for platform teams: revisit which third-party tools you actually still need now that Snowflake bundles more capabilities at no incremental cost.

Key Takeaways

• May 19, 2026 brought column-level lineage to dbt Projects on Snowflake, visible in Workspaces, project object details, and Query History.
• The DAG gained an in-DAG search bar, expandable upstream/downstream depth controls, a unified side panel (row count, column count, compiled SQL, runtime), and a model display limit increase from 100 to 300.
• The Horizon Catalog is the single source of truth for the new lineage view.
• dbt Fusion engine (Rust runtime) is now supported on dbt Projects on Snowflake; no licensing fee, no user limits, but currently a preview release.
• Multi-version support landed via the DBT_VERSION parameter, with DEFAULT_DBT_VERSION as the account-level default. Supported versions include dbt Core 1.9.4, 1.10.15, and dbt Fusion 2.0.0-preview.
• For teams that bought a third-party catalog mainly for column-level dbt lineage, this update is a reason to revisit that contract.

Frequently Asked Questions

What changed in dbt Projects on Snowflake on May 19, 2026?

The DAG now shows columns inside each model node and supports column-level lineage across Workspaces, project object details, and Query History. Additional changes: in-DAG search, expandable depth controls, unified side panel (row count, column count, compiled SQL, runtime), and a model display cap increase from 100 to 300.

Where does the column-level lineage data come from?

The Snowflake Horizon Catalog is the single source of truth, which keeps lineage consistent between the dbt project object detail page, the Workspace DAG, and the Query History DAG.

What is the dbt Fusion engine?

A ground-up rewrite of the dbt runtime in Rust, designed to improve compilation times as project complexity grows. It is supported by dbt Projects on Snowflake with no additional licensing required and no user limits, but it currently ships as dbt Fusion 2.0.0-preview.

How do I pin a specific dbt version?

Use the DBT_VERSION parameter when creating a dbt project object, or override it at runtime. Set DEFAULT_DBT_VERSION for the account default. Supported versions include dbt Core 1.9.4, dbt Core 1.10.15, and dbt Fusion 2.0.0-preview.

Do I have to migrate to Fusion to get the new lineage view?

No. The column-level lineage view applies to dbt Projects on Snowflake regardless of which supported runtime version a given project is pinned to.