The dbt Semantic Layer requires dbt Cloud. Here is what that actually costs you.
MetricFlow is open source and genuinely good. The part that lets anything other than your own terminal query a metric is not. If you are costing a semantic layer for agents, that line is where the bill starts, and it is worth understanding before you compare anything else.
What dbt gets right, and it is most of it.
dbt won the transformation layer because it was correct about where metric definitions belong. Nothing below is a criticism of that.
The definition sits next to the model that builds it
A metric defined in the same project as the tables underneath it is a metric that gets updated when those tables change. Every semantic layer that lived in a BI tool learned this the expensive way.
MetricFlow is open source
You can define semantic models and metrics in dbt Core and query them from the command line without paying anyone. That is more than most of this category offers, and it means your definitions are portable even if your access to them is not.
It compiles rather than caches
MetricFlow generates SQL for the grain you asked for, including the joins and the aggregation. No cube to rebuild and no pre-materialised grain to outgrow, which is the failure mode of the generation before it.
The people who own the transformations own the metrics
One team, one repository, one review process. The organisational argument for dbt is stronger than the technical one and it is the reason it stuck.
What runs on dbt Core, and what needs a paid dbt plan.
The Semantic Layer is not one thing. It is a specification you can use for free and a service you cannot, and almost every evaluation confuses the two.
dbt's own documentation is clear about the split. dbt Core users can define metrics with MetricFlow and query them locally from the command line, and the docs say so directly. What they cannot do is reach those metrics through the APIs or the integrations, and that is what anything other than a person at a terminal has to use.
| Capability | dbt Core and MetricFlow | Paid dbt platform plan |
|---|---|---|
| Define semantic models and metrics in YAML | Yes | Yes |
| Query a metric from the command line | Yes | Yes |
| Validate definitions in CI | Yes | Yes |
| JDBC, GraphQL and ADBC Semantic Layer APIs | No | Yes |
| BI and spreadsheet integrations | No | Yes |
| Anything programmatic, including an agent | No | Yes |
| Result cache and declarative cache | No | Listed by dbt as a higher-tier feature |
| Multiple warehouse credentials | No | Listed by dbt as a higher-tier feature |
The practical consequence: the moment your semantic layer has a consumer that is not a human running dbt sl query, you are on a paid plan. An agent is exactly that consumer. So is a dashboard, and so is the notebook someone on your team will write in the second week.
We are not going to quote dbt a price. Plan names have changed more than once, pricing is per seat plus consumption in ways that depend on your shape, and a comparison page carrying a stale number is worse than one carrying none. Read it from dbt's own pricing page and cost it against your actual seat count, then come back to the rest of this.
The warehouse executes everything. Including ours.
This is the row most comparison pages get dishonest about, so it is worth being plain.
MetricFlow does not hold your data and does not execute anything. It generates SQL, hands it back to dbt's gateway, and the gateway runs it on your data platform. Every metric query is warehouse compute on your warehouse bill, and concurrency is your warehouse's problem.
Ward works the same way, and anyone who tells you their semantic layer is free of warehouse cost is selling you a cache with a different name. We push compute down to the source too. What changes with agents is not the unit cost of a query, it is the number of them: a human opens a report once a week and an agent resolves the same metric two hundred times an hour, and that arithmetic lands on the same bill whichever layer generated the SQL.
The thing worth costing, then, is not which layer is cheaper per query. It is whether the layer gives you anything that reduces the query count or caps it, and what happens to your bill on the day someone points a badly written agent at it.
There is a cache. It is a higher-tier feature.
The brief for this page said the dbt Semantic Layer has no pre-aggregation cache. That is not accurate and the accurate version is more useful.
dbt's documentation describes two layers of caching, a result cache and a declarative cache, both of which live in your data platform, and lists caching among the features of its higher plans. On the entry plan there is no cache, which is the version of this claim that survives checking.
Separately, and on all plans, exports and saved queries let you materialise a metric into a table or a view on a schedule. That is pre-aggregation, and it works. It is also a thing you build, schedule and maintain, which is the same job the cube you replaced was doing, so it is worth counting as pipeline work rather than as a property of the layer.
For an agent workload the distinction matters more than it does for dashboards. Agents ask unpredictable questions at unpredictable grains, which is exactly the pattern a scheduled export cannot anticipate and a result cache only helps with on the second identical call.
dbt ships an official MCP server. The question is what it is scoped by.
This page was scoped with "dbt has no official MCP server". That was wrong when it was written, so here is the correction rather than the claim.
dbt Labs publishes dbt-mcp, an Apache 2.0 licensed MCP server, and its Semantic Layer tools include list_metrics, get_dimensions and query_metrics. An agent can discover your metrics and resolve them through the definition rather than writing its own SQL, which is the important property and dbt has it.
Two things follow from how it is built. The Semantic Layer tools reach your metrics through the Semantic Layer APIs, so they inherit the paid-plan requirement from the section above: the MCP server is free and the surface it talks to is not.
The second is the one to take to your security review. The unit of access control is the credential the Semantic Layer query runs under and the warehouse role behind it. That is a real control and for many teams it is a sufficient one. What it is not is a per-agent scope evaluated on every call, and it does not produce a single log in which a person and an agent resolving the same metric appear as two rows with the same shape. If the question you have been asked is what that agent read last Tuesday, you answer it from warehouse query history and correlate by credential, which works and takes an afternoon.
The schema for the log that answers that question in a minute instead, field by field, with the DDL. The audit log schema →
When dbt Semantic Layer is the right answer.
Often. These are not consolation cases, they are the majority of teams reading this page.
- Your transformations are already in dbt and your team reviews them properly. The semantic layer is a few days of work on a foundation you have, not a new system.
- Your consumers are people and BI tools. The dbt Cloud requirement is a line item you were paying anyway, and the integrations are the reason you pay it.
- You want metric definitions in version control, reviewed as code, with a CI gate. dbt does this better than anything else in the category and Ward does not try to.
- Your data is in one warehouse and you are happy for it to stay there.
- You have a data team that will own MetricFlow. It rewards ownership and it punishes neglect.
If you run dbt, keep it.
Ward is not a replacement for a transformation layer and does not have one worth the name. Ward imports an existing dbt project, keeps dbt as the thing that builds your tables, and resolves and scopes the query on top. The part that changes is what happens between an agent and the definition: scope evaluated per call against the agent identity, and one log covering people and agents in the same rows. If nothing is querying around your semantic layer today, you do not have the problem this page is about.
The longer version, for the person who owns the warehouse: for data and analytics leaders. The category argument: a semantic layer an agent cannot route around.
The questions that arrive with this one.
Answered without assuming you have picked a side. Every claim about dbt Semantic Layer here is checkable in their documentation.
The specification does not and the service does. You can define semantic models and metrics with MetricFlow in dbt Core and query them locally from the command line without paying dbt anything. The Semantic Layer APIs, the JDBC, GraphQL and ADBC endpoints, and the BI integrations are part of dbt's hosted platform and require a paid plan. Since anything other than a person at a terminal has to go through those APIs, in practice a semantic layer with programmatic consumers is a paid dbt plan.
Yes. MetricFlow is open source and dbt Core users can define metrics and query them from the command line. What you lose is dynamic access: no APIs, no integrations, and nothing an application or an agent can call. Teams in this position usually end up writing their own service in front of MetricFlow, which works and is a thing you then own.
Yes. MetricFlow generates SQL and hands it to dbt's gateway, which executes it against your data platform. The Semantic Layer does not store your data and does not have its own compute, so every metric query is warehouse compute on your bill. This is true of Ward as well. The number that changes when agents arrive is not the cost per query, it is the number of queries.
dbt's documentation describes a result cache and a declarative cache, both living in your data platform, and lists caching among its higher-plan features. Separately, exports and saved queries can materialise a metric into a table or view on a schedule on any plan, which is pre-aggregation you build and maintain rather than a cache the layer keeps. For agent workloads, where the questions and grains are unpredictable, scheduled exports help less than they do for dashboards.
Yes. dbt Labs publishes dbt-mcp, an official Apache 2.0 licensed MCP server, and its Semantic Layer tools include list_metrics, get_dimensions and query_metrics, so an agent can resolve a metric through its definition rather than writing raw SQL. Note that those tools reach your metrics through the Semantic Layer APIs, so using them requires a paid dbt plan even though the MCP server itself is free.
dbt is a transformation layer with a semantic layer on top of it, built for a team that owns a repository. Ward is a warehouse, a semantic layer and an agent runtime in one console, built for a team that wants the definitions reconstructed from the reports they already publish rather than authored from scratch. The technical difference that matters for agents is the access control unit: dbt scopes a Semantic Layer query by the credential it runs under, and Ward evaluates policy per call against the agent identity and logs people and agents in one place. They coexist. Ward imports an existing dbt project rather than replacing it.
If dbt is the only route anyone takes to your data, your definitions are already in one place and you have most of the value. The gap opens when something queries around it. An agent holding a warehouse credential does not run dbt: it writes SQL, and dbt has no opinion about what that agent may read and no record of what it read. The question to ask is not whether you have a semantic layer, it is whether anything can reach your data without going through it.
Check it rather than take it from us.
Free to deploy, 5% of model spend
No license, nothing per seat. Setup is one-time: $0 self-guided, $7,500 guided, $20,000 managed, $50,000 and up for a program.
See the numbers →The audit log, with the schema
What a complete agent audit record contains, field by field, with copy-pasteable DDL and the SOC 2 mapping.
Read the schema →The governed MCP server
The tools an agent can call, the three permission layers that gate them, and a worked example with the warehouse grants.
Read the reference →The 48-hour test protocol
A vendor-neutral acceptance test you can run against us, against them, or against both.
Run the protocol →Claims about dbt on this page are taken from dbt Labs' own public documentation and the dbt-labs/dbt-mcp repository, checked on 20 September 2026. Specifically: the plan split and the caching description come from dbt's Semantic Layer FAQ, the execution model from dbt's description of how MetricFlow hands SQL to its gateway, and the MCP tool list from dbt's MCP documentation. No dbt pricing is quoted here on purpose, because plan names and prices change and a stale number is the fastest way to make a page like this untrustworthy. Where this page says "a paid plan" or "a higher tier", that is dbt's framing and not a specific product name, and you should read the current tiers from dbt. If you find a row here that is out of date, it is a mistake rather than a position: write to brian@askotter.ai and it will be corrected or removed.
Run the test rather than take the page for it.
Deploying is free, so an evaluation costs you a credential and two days.
Read-only to start · your LLM keys · SOC 2 Type II underway · or book a call directly
Find out what your data has been hiding.
Tell us about your operation. We’ll show you the problems Ward catches, and the ones your current tools miss.