Snowflake Semantic Views vs dbt Semantic Layer: Which Should Own Your Metrics?
The short answer
Pick the owner before you pick the tool
Ask an AI agent for last quarter's net revenue and it will give you a number. Ask it again through a different tool and you may get another number. Both will sound equally confident.
Snowflake Semantic Views and the dbt Semantic Layer both exist to prevent this. The question is which one should own the definition. For a Snowflake-centred estate, native Semantic Views are often the simplest answer. Where metrics must serve several platforms and tools, or where dbt already governs the business logic, the dbt Semantic Layer is usually the stronger owner. Using both is legitimate, provided only one of them is authoritative.
Why AI agents disagree on business metrics
The same number, defined twice
Net revenue is gross sales less discounts, excluding cancelled orders. Finance defines it in dbt, because that is where transformation logic is reviewed. Later, another team builds an agent on Snowflake and describes net revenue again in a semantic view, because that is what the agent reads.
Then finance changes the rule: refunds now count against the month of the original sale. The dbt definition is updated through a pull request. The semantic view is not. Both still return plausible numbers.
The consequences start small. The management pack and the sales leader's agent show different revenue for the same quarter. Analysts spend days reconciling them, and nobody is sure who owns the definition. As more teams build agents on their own copies of definitions, trust in all of them erodes, and scaling agents across functions gets harder than building the first one.
A person usually notices when two reports disagree.
Where a metric is defined matters more than how it is defined.
Agents do not resolve ambiguity. They inherit it. An agent that chooses its own tools and composes its own queries cannot be guaranteed consistent answers when the semantic sources behind those tools disagree.
Two approaches to governing business meaning
Snowflake Semantic Views and the dbt Semantic Layer
Snowflake's semantic layer is built from semantic views. A semantic view is a schema-level object inside the platform. It holds the logical tables, relationships, dimensions, facts and metrics that describe how the business uses its data. It is queried with SQL and read directly by Cortex Analyst and Cortex Agents, and Snowflake recommends semantic views for new Cortex Analyst work.
The dbt Semantic Layer starts from definitions held in the dbt project, next to the models that produce the data. MetricFlow, the open-source engine, turns a metric request into SQL for the underlying platform. The managed Semantic Layer adds APIs so other tools can query the same definitions, and an MCP server lets AI tools use governed metrics.
Snowflake Semantic Views vs dbt Semantic Layer
Where they differ in practice
Authoring and governance. Semantic Views are authored as Snowflake objects and governed by Snowflake privileges. A role needs access to the view, not to every table beneath it. dbt definitions are code in the project, so review, versioning and testing come with the workflow. A semantic view can be given the same discipline, but you have to build it.
Execution and AI consumption. Semantic Views run on Snowflake compute and are native to Cortex agents. dbt definitions are executed by MetricFlow on the warehouse and reached through the Semantic Layer's APIs or MCP server, so each AI consumer has to be connected to them.
Portability and dependencies. Semantic Views are platform-native. They are available outside Snowflake only through Snowflake's own interfaces. MetricFlow works across Snowflake, BigQuery, Databricks, Redshift and Postgres. The managed Semantic Layer and its APIs require a paid dbt plan, while Cortex Analyst usage is billed per message, with warehouse compute for the generated SQL charged separately.
The architectural mistake: confusing availability with authority
Authority, propagation and consumption
Three responsibilities are often blurred together. Authority is who owns and approves the business definition. Propagation is how that definition is carried into every system that uses it. Consumption is how BI tools, applications and agents reach it.
Metric authority is not the same as metric availability. A metric can be available through several tools, warehouses and agent interfaces while being authoritative in only one governed definition.
A single source of truth does not require a single semantic technology. It requires clear ownership, controlled propagation and demonstrable consistency.
Defining a metric twice is the problem. Using two tools is not.
Propagation is where designs are usually weaker than they look. Snowflake Labs maintains a dbt package that lets teams author a semantic view inside a dbt model and deploy it as a native Snowflake object. That brings version control and review to the view, and it answers the question of whether dbt supports Snowflake Semantic Views. It does not translate MetricFlow metrics into the view: the package works from a semantic view definition written directly in the model. A team that keeps MetricFlow metrics and dbt-managed semantic views still maintains two definitions, only in the same repository.
How meaning is distributed across layers is a design question of its own, covered in How to Give AI Agents Consistent Business Meaning.
How to choose where metrics should live
Three architectural patterns
The best architecture is the least complex one that meets your consumption and governance requirements. Three patterns cover most cases.
Pattern A: Snowflake-centric. Most data and most consumers sit in Snowflake, and agents run on Cortex. Semantic Views can be both the authoritative definition and the serving layer. The path from governed metric to agent is short, and the views can still be deployed through a dbt pipeline for review without handing authority to a second system. Our guide to making Snowflake AI-ready without rebuilding your data platform shows where this fits.
Pattern B: cross-platform or established dbt. Metrics serve several warehouses, BI tools or applications, or dbt is already where finance logic is reviewed. The dbt Semantic Layer owns and serves the definitions, and every consumer reaches them through the same interfaces. The trade-off is that Snowflake agents reach the definitions through those interfaces, not by reading a native Snowflake object.
Pattern C: Snowflake AI consumption with existing dbt investments. dbt owns the definition and Semantic Views serve Cortex agents. This is justified only when agents need native Snowflake integration and the logic must stay in dbt. It requires an explicit propagation step and reconciliation testing. If Snowflake is the only consumer, Pattern A is simpler.
Four questions usually settle it: how many platforms use the metric, where the business already approves its logic, where agents run, and who can approve a change.
How to prevent semantic drift across systems
Ownership, deployment and reconciliation
- Name one owner per metric. A business role owns each definition, not a tool.
- Treat the authoritative definition as code. Review it, version it and deploy it through a pipeline. Forbid edits in the serving layer.
- Deploy rather than retype. Where a translation is manual, make it a recorded, reviewed step.
- Reconcile automatically. Run the metrics that matter through every serving layer, compare the results and stop the release when they differ.
Be realistic about interoperability standards. The Open Semantic Interchange initiative is now Apache Ossie, accepted into the Apache Incubator in July 2026 and aiming at a vendor-neutral format for semantic models. Reference converters exist for MetricFlow, Snowflake semantic models and Apache Polaris, and dbt can read Ossie documents. The specification is still evolving, and a converter is a translation step, not a guarantee that definitions stay aligned. Treat the standard as a direction of travel and keep the tests.
The decision that matters
Who owns net revenue?
Choosing between the two technologies is a smaller decision than choosing who owns net revenue. That is a governance decision for the business. Technology only carries it out.
Reliable enterprise AI depends on authoritative, consistently propagated business semantics. Where those hold, an agent can use any tool and arrive at the same number.
FAQ
Can Snowflake Semantic Views and the dbt Semantic Layer be used together?
Yes, provided only one of them is authoritative for each metric. A common pattern is dbt as the source of the definition and Semantic Views serving Cortex agents, with reconciliation tests between them. If Snowflake is the only consumer, Semantic Views alone are simpler.
Does dbt support Snowflake Semantic Views?
Yes. The Snowflake Labs dbt_semantic_view package lets you define a semantic view inside a dbt model and deploy it as a native Snowflake object. It does not translate MetricFlow metrics into semantic views, so the two remain separate definitions.
What is the difference between a Snowflake semantic view and a semantic model?
In Snowflake, a semantic model usually means the older YAML file stored on a stage that Cortex Analyst read. A semantic view is a schema-level object governed by Snowflake privileges. Snowflake recommends semantic views for new work and still supports the YAML files for backward compatibility. dbt uses the same words for its own YAML definitions, which are a different thing.
How do semantic layers support AI agents?
They give an agent governed definitions of entities, metrics and relationships, so it does not have to infer them from table names or prompts. Consistent answers still depend on the definitions behind every tool agreeing with each other.