SQLMesh

Extend SQLMesh lineage beyond its own DAG into every source, warehouse table, semantic layer, and dashboard that touches it.

Transformation & Orchestration

Why SQLMesh matters

SQLMesh brings virtual environments, built-in change categorization, and incremental-by-default models, but its lineage stops at its own boundary. It does not know what upstream sources feed into it or what downstream BI dashboards and semantic layers consume its output. Teams running SQLMesh alongside dbt during a migration have lineage split across both tools.

Typedef connects SQLMesh to the full platform, giving you one graph that spans transformation tools, warehouses, and every consumer, so impact analysis covers the complete stack.

What Typedef unlocks

Full-stack impact analysis

Before changing a SQLMesh model, see every downstream dashboard, metric, and consumer affected across the entire platform.

Unified cross-tool lineage

For teams running SQLMesh and dbt side by side, see one connected graph across both tools and every system in the stack.

Metric provenance

Trace business metrics from the BI layer back through SQLMesh models to upstream sources, surfacing where definitions are calculated and where they diverge.

Transformation migration confidence

Plan dbt-to-SQLMesh migrations (or the reverse) with full visibility into what depends on each model across every system.

Related integrations

Bridge the gap between execution order and data dependencies so pipeline failures are scoped by business impact.

Connect Dagster assets to every source, consumer, and BI tool outside its scope so the asset graph becomes a full-stack view.

Go beyond the DAG: trace every model through the full platform, not just the project.