// the find
dbt-labs/metricflow
MetricFlow allows you to define, build, and maintain metrics in code.
MetricFlow is a semantic layer that sits on top of dbt projects and compiles metric definitions into engine-specific SQL. You define metrics once in YAML, and it handles the join logic, time granularity aggregation, and dimension traversal across your warehouse. It's for data teams who are tired of copy-pasting the same revenue calculation twelve different ways across their BI tools.
The dataflow plan architecture is genuinely well-designed — metric requests compile into an intermediate DAG that gets optimized before SQL generation, so you get column pruning and source scan deduplication without hand-tuning. Multi-hop joins and cumulative metrics are first-class, not afterthoughts bolted on. The license history (AGPL → BSL → Apache 2.0) shows they eventually committed to a real open-source model, which matters for adoption. The OSI initiative backing from Snowflake and dbt Labs means the semantic manifest format has a chance of becoming a cross-tool standard rather than another walled garden.
It's not usable without a dbt project — the standalone `metricflow` package exists but the CLI and all practical tooling assumes `dbt-metricflow`, which means you're adopting dbt's entire DAG execution model as a prerequisite. The SQL optimization pipeline is sophisticated but the complexity shows: the `dataflow/` and `plan_conversion/` trees are dense and poorly documented, making it hard to debug why a generated query looks the way it does. 1,622 stars for a project this mature signals limited adoption outside the dbt ecosystem; if your team isn't already dbt-native, the onboarding cost is steep. Saved queries and the semantic manifest spec are still evolving, so YAML schemas you write today will likely need updates as the OSI standard solidifies.