Debate: define metrics directly in dbt
A social post argues for defining metrics directly in dbt rather than in separate tools, claiming this reduces drift and improves maintainability by keeping business logic where transformations live. The idea is to avoid multiple metric sources that fall out of sync, but it raises tradeoffs around who owns metric governance and how non‑dbt consumers access certified definitions. (x.com)
A fight that used to happen quietly inside analytics teams is now out in public: should a company’s definition of “revenue” live in the dashboard tool, or in dbt, the transformation layer that already builds the tables underneath it. dbt’s current docs explicitly tell teams to define metrics in YAML inside the dbt project, and its Semantic Layer says those definitions can then be reused across downstream tools. (docs.getdbt.com 1) (docs.getdbt.com 2) The case for putting metrics in dbt is simple: the model logic and the metric logic usually change together. If a team renames a column, changes a join, or redefines “active customer” in the transformation code, keeping the metric in the same repository means the pull request can update both in one place under version control. (docs.getdbt.com 1) (docs.getdbt.com 2) That is the “drift” people are arguing about. One team updates a Snowflake or BigQuery model on Monday, another team forgets to update the Tableau or Power BI calculation on Tuesday, and by Wednesday two executives are looking at two different numbers with the same label. (docs.getdbt.com) (www.getdbt.com) dbt’s answer is MetricFlow, the engine behind its Semantic Layer. dbt says MetricFlow generates the Structured Query Language, handles joins across semantic models, and lets teams define simple, ratio, cumulative, derived, conversion, and other metric types directly in the project. (docs.getdbt.com 1) (docs.getdbt.com 2) That matters because business metrics are rarely just one column with a SUM around it. dbt’s metric spec supports filters, time windows, and formulas that reference other metrics, which means “net revenue retention” or “seven-day active users” can be stored as code instead of re-created by hand in every reporting tool. (docs.getdbt.com) The argument gets stronger when a company uses five or six consumption tools at once. dbt lists native or documented Semantic Layer integrations for Power BI, Tableau, Google Sheets, Microsoft Excel, Hex, Mode, Sigma in preview, and several others, plus custom access through GraphQL, Java Database Connectivity, Arrow Database Connectivity, and Python. (docs.getdbt.com) That is also where the pushback starts. If the certified metric lives in dbt, the center of gravity moves toward the analytics engineering team that owns the repository, not the finance analyst in Excel or the business intelligence developer who used to certify a dashboard inside Tableau. (docs.getdbt.com) (docs.getdbt.com) There is also a product boundary in dbt’s own stack. dbt says Core users can define metrics in projects and query them locally with MetricFlow, but the APIs and first-class downstream integrations that make those definitions broadly reusable sit behind dbt Starter, Enterprise, or Enterprise Plus plans. (docs.getdbt.com) (docs.getdbt.com) So the real debate is not “should metrics be code” versus “should metrics be charts.” It is who gets to own the business definition, how portable that definition is across tools, and whether the company wants one repository to act like the source code for every number on every dashboard. (docs.getdbt.com) (www.getdbt.com) dbt has been pushing that idea for years, and in December 2025 it went further by moving MetricFlow to the Apache 2.0 license and tying it to open semantic interoperability efforts with partners including Snowflake and Salesforce. That turns a workflow argument inside data teams into a standards argument about whether metric definitions should be portable infrastructure, like Structured Query Language itself, instead of settings trapped inside one vendor’s dashboard product. (www.getdbt.com)
