How it works

BlastRadius answers two questions about your data warehouse, at column level:

Upstream: where does this column actually come from?
Blast radius: if I change or drop this column, what breaks downstream?

Inputs

Two ways in:

dbt manifest.json — drop the artifact from dbt compile or dbt docs generate. BlastRadius parses the compiled SQL of every model, seed, and snapshot, plus source definitions.
Raw .sql files — one model per file; the filename becomes the model name. Cross-file references resolve against each other; anything unresolvable is shown as an unknown node.

What it understands

Column renames (id AS customer_id) traced through the rename.
Expressions (amount_cents / 100.0) — every referenced column is a dependency.
CTEs, joins with aliases, derived tables, scalar subqueries.
SELECT * — expanded against known upstream columns, and every link it creates is flagged via * so you know it's a star dependency.

Honesty rules

A lineage tool that guesses is worse than no tool. BlastRadius follows three rules:

Never fake precision. If a table can't be resolved (missing source, dynamic SQL), it's shown as an unknown node with the referenced name — not silently dropped.
Ambiguity is surfaced. An unqualified column present in two joined tables links to both and is flagged ambiguous.
Aggregates are honest. count(*) has no column inputs, so its lineage is empty — not invented.

Privacy

Everything runs in your browser. The SQL parser is vendored locally (node-sql-parser), there are no CDNs, no analytics, no network calls. Your warehouse schema never leaves your machine.

Try it

Click Try the demo project on the analyzer: an 8-node dbt project with renames, a CTE, joins, expressions, and a SELECT *. Pick mart_vip_customers → total_spent and watch the blast radius light up.