Executive summary
The dbt Semantic Layer (powered by MetricFlow) brought metric consistency to the modern data stack. Defined in YAML alongside your dbt models, MetricFlow metrics resolve to consistent values whether they are queried from Tableau, Looker, Power BI, or a notebook. For BI tools that previously each maintained their own version of "monthly active users," that consistency is genuinely valuable.
Colrows is built for the layer above that. Where dbt SL stops at metric values, Colrows operates on meaning: a typed semantic graph of entities, relationships, multi-scope policies, and compile-time governance that AI agents reason on directly. Where dbt SL is hand-authored YAML refreshed by humans, Colrows builds and maintains its graph autonomously. Where dbt SL exposes a metric API, Colrows compiles agent intent into dialect-perfect SQL.
In short:
- dbt Semantic Layer helps BI tools agree on metric values.
- Colrows enables AI agents to compile intent into governed, deterministic SQL.
The two are complementary at the data layer and divergent at the application layer.
Two philosophies, two outcomes
dbt Semantic Layer assumes meaning is versioned alongside transformations. You author semantic_models in YAML, declare measures and dimensions, and rely on MetricFlow to stitch them into queries at runtime. The metric definition lives next to the dbt model that produces the underlying table - a sensible coupling that mirrors how analytics engineering teams already work.
Colrows assumes meaning is distributed across the enterprise. dbt models are one input, but so are the warehouse catalogue, BI tools, Confluence, runbooks, data dictionaries, and historical query usage. Colrows ingests these sources and constructs a typed semantic graph autonomously. The graph is multi-scope (global, datastore, persona, user) and uses multi-vector embeddings (definition, usage, combined per concept).
The downstream consequence: dbt SL keeps your BI tools in agreement on existing metrics. Colrows keeps an evolving graph in agreement with the entire data estate, ready for AI agents to reason on.
Metric layer vs. semantic graph
The most important architectural distinction is what the layer actually models.
dbt Semantic Layer models metrics. A measure (e.g. order_total), aggregated across dimensions, possibly filtered, possibly with time-based windows. The output is a value or a small result set.
Colrows models a graph. Concepts (Customer, Subscription, Order), the typed relationships between them (Customer has Subscription, Order belongs to Customer), governance predicates attached at every node and edge, and the proven join paths an AI agent must traverse to answer a multi-hop question.
Metrics are a subset of a semantic graph. Every dbt SL metric can become a node in a Colrows graph. Not every Colrows-graph node is a metric.
A concrete scenario: regulated SaaS retention analysis
An enterprise SaaS company runs dbt extensively. Its analytics engineering team has authored a clean dbt project, and a few dozen MetricFlow metrics power consistent dashboards across Looker and Tableau. Monthly recurring revenue, churn rate, expansion ARR - all accurate, all repeatable.
The customer success team now wants an AI agent that can answer: "Which mid-market accounts in EMEA at risk of non-renewal in the next 60 days have skipped key features in their adoption journey, and what does the regulatory scope of those accounts allow our agent to share back to the CSM?"
dbt SL can return the metric values: renewal_risk_score, feature_adoption_rate. But the agent has to reason across:
- The Account, Subscription, FeatureAdoption, Renewal, and ComplianceScope entities and the relationships between them.
- The CSM persona's permission to see specific account columns.
- Regulatory predicates that vary per region (e.g. data minimisation rules in some EU customers).
- An audit trail proving exactly which metric definitions and policies were in force when the agent answered.
None of these are metric questions. They are graph questions, governance questions, and compilation questions. With Colrows, the agent compiles its intent through a typed graph that already encodes those entities, policies, and scopes; the dbt-defined metrics are nodes in that graph, but they are not the whole story.
Why metric layers cannot do this alone
dbt Semantic Layer is excellent at one thing: ensuring metric consistency across BI consumers. It is not designed to:
- Encode entity-and-relationship models for multi-hop agent reasoning.
- Enforce policy at compile time across persona, tenant, and regulatory scope.
- Build or maintain itself from documentation, runbooks, and usage signals.
- Produce machine-readable compile traces for AI audit.
- Resolve the same concept differently per tenant or persona without forking the metric.
Each of those is foundational for putting AI agents into production. Adding them on top of MetricFlow is not a configuration change - it is a different architecture above the metric layer.
What evaluators actually compare
Plan requirement and pricing
The dbt Semantic Layer is a paid-platform feature. dbt's documentation states that defining and querying metrics requires a dbt Starter or Enterprise-tier account; dbt Core users can author MetricFlow YAML locally but cannot query metrics through the APIs or integrations. As of June 2026, dbt's published pricing puts Starter at $100 per user per month with 5,000 queried metrics per month included; Enterprise (custom pricing) includes 20,000 queried metrics per month plus advanced features such as caching and multiple credentials. Note the consumption meter: per dbt's billing docs, "every successful request you make to render or run SQL to the Semantic Layer API counts as at least one queried metric" - a meter that AI-agent workloads, which issue queries continuously, will run hot against.
Colrows has a free tier with unlimited datasources, users, and access policies, and custom Enterprise pricing for SSO/SCIM, dedicated infrastructure, and SOC 2 / HIPAA-aligned deployments.
Modeling effort
The Semantic Layer is hand-authored YAML, and dbt is candid about what that costs. Dave Connors, the dbt Labs product manager for the spec, wrote in January 2026: "We've heard from numerous community members over the years that defining metrics was just plain hard" - citing deep YAML nesting, fragmentation across files, and redundant duplication of column properties. Two structural requirements deserve line items in your evaluation: MetricFlow's mandatory time spine ("to use MetricFlow with time-based metrics and dimensions, you must provide a time spine" - a dbt model you build and configure yourself), and the single global namespace - every entity, dimension, measure, and metric name is registered project-wide, so a second domain that also needs total_sales collides with the first and forces prefixing conventions.
Colrows resolves the same concept differently per scope by design - the semantic graph is multi-scope (global → datastore → persona → user), so total_sales can mean what each domain needs it to mean without a naming convention holding the system together. And the graph is built autonomously, with dbt definitions as one ingested input rather than the authored artifact.
Integration surface
dbt SL's native integrations cover a specific list - Power BI, Tableau, Google Sheets, Excel, Hex, Mode, Omni, Sigma (preview), and a few others - with everything else reaching metrics through JDBC/ADBC/GraphQL APIs or exports. If your consumers are AI agents rather than BI tools, the relevant surface is different: Colrows exposes HTTP, JDBC, and MCP endpoints where every call goes through the same compile-then-execute pipeline with join path proof and an audit trail per query.
Migration and coexistence
This is not a rip-and-replace decision. Keep dbt for transformations and metric definitions; Colrows ingests semantic_models YAML to seed its graph, then extends it with entities, relationships, and policies the metric spec does not model. Existing MetricFlow investment carries forward instead of being rewritten.
What dbt's own evidence says
The strongest third-party validation of the compile-then-execute thesis comes from dbt Labs itself. Their April 2026 benchmark (11 insurance-domain questions, 20 runs each) found that routing LLM questions through the Semantic Layer raised accuracy from 90.0% to 98.2% for one frontier model and from 84.1% to 100% for another, because - in their words - "the Semantic Layer's deterministic query generation means the LLM can't produce subtly wrong results." Their sharpest line: "With text-to-SQL, failure looks like a plausible but incorrect answer. With the Semantic Layer, failure looks like an error message."
The same benchmark also shows where the metric-layer ceiling sits: on questions requiring too many entity hops, the Semantic Layer scored 0% - it errored rather than answered, because multi-hop entity traversal is outside what a metric spec models. That is precisely the boundary a typed semantic graph with join path proof exists to cross. Deterministic compilation is the right foundation; the question is whether the thing being compiled against models metrics or models the enterprise. The full evidence base - including enterprise text-to-SQL benchmarks - is in our pillar on deterministic vs probabilistic text-to-SQL.
Pricing, plan names, and benchmark figures reflect the cited dbt pages as of June 2026 and are dbt's published claims, reported with attribution.
Reframing the comparison
dbt Semantic Layer and Colrows operate at different altitudes of the stack.
dbt Semantic Layer = metric layer co-located with transformations. Optimised for BI consistency. Manual YAML authoring. Resolution at query time inside MetricFlow.
Colrows = semantic execution layer above the warehouse. Optimised for AI agent compilation. Autonomous graph construction. Resolution at compile time, with governance injected before SQL emits.
The two coexist cleanly: keep dbt for transformations and metric definitions; add Colrows for the agent-execution surface that ingests those metrics and compiles agent intent against the broader graph.
The bottom line
If your goal is consistent metric values across BI tools - one definition of revenue, churn, or active users - dbt Semantic Layer is well-suited and integrates cleanly with the analytics engineering workflow you already run.
If your goal is to put AI agents into production - to compile their intent into governed SQL with proven join paths, compile-time policy enforcement, and a continuously maintained semantic graph that evolves with your business - dbt SL alone is not the right architecture. The semantic execution layer above it is what matters, and that is what Colrows provides.
At the core
| dbt Semantic Layer | Colrows | |
|---|---|---|
| Built for | BI metric consistency | Semantic execution for AI agents |
| Primary consumer | BI tools, notebooks, humans | AI agents, autonomous workflows |
| Core strength | One definition of each metric | Governed compilation of agent intent |
| Intelligence lives in | YAML metric definitions | Typed semantic graph |
Semantic and intelligence handling
| Capability | dbt Semantic Layer | Colrows |
|---|---|---|
| What is modelled | Measures, dimensions, time grains | Entities, relationships, policies, examples, multi-scope |
| Authoring model | Manual YAML alongside dbt models | Autonomous, ingests dbt definitions and more |
| Multi-scope resolution | No - one metric definition globally | Yes - global, datastore, persona, user scopes |
| Context preservation | Per-query | Cross-workflow, persistent |
| AI readiness | Indirect - via metric API | Agent-native by design |
| Explainability | Metric definition lookup | End-to-end (intent → semantics → SQL → source data) |
Engineering and operational reality
| Dimension | dbt Semantic Layer | Colrows |
|---|---|---|
| Compile-time governance | Limited - relies on warehouse policy | Yes - RBAC/ABAC injected into generated SQL |
| Join path proof | Implicit via dbt model lineage | Proven against typed graph at compile time |
| Drift handling | Manual updates by analytics engineers | Autonomous detection plus proposed mappings |
| Hosting requirement | dbt Cloud subscription | Free tier, Cloud, or self-hosted (Enterprise) |
| Audit trail | Query and version history | Point-in-time reproducible compilation trace |
| Coexistence | - | Ingests dbt SL definitions; dbt continues to transform |
Frequently asked questions
Does Colrows replace dbt?
No. dbt is a transformation framework that builds and tests models inside your warehouse. Colrows sits above the warehouse and compiles AI agent intent into governed SQL. Most teams keep dbt for transformations and add Colrows for the agent-execution surface.
Does Colrows replace the dbt Semantic Layer (MetricFlow)?
Colrows can ingest dbt Semantic Layer metric definitions and use them to seed its semantic graph. Where dbt SL stops at metric values exposed to BI tools, Colrows continues into entity modelling, multi-scope resolution, compile-time governance, and agent-native compilation. For BI consistency, dbt SL is sufficient. For AI agent execution, the graph layer above it is what matters.
Why is a metric layer not enough for AI agents?
AI agents reason across entities and relationships, not just measures. A metric layer can return monthly active customers but cannot prove the join from Customer to Subscription to UsageEvent under tenant-specific governance, or inject row/column-level predicates into the generated SQL at compile time. Those are graph-level capabilities.
How much does the dbt Semantic Layer cost?
It requires a paid dbt platform plan. As of June 2026, dbt's published pricing puts Starter at $100 per user per month with 5,000 queried metrics per month included; Enterprise (custom pricing) includes 20,000 queried metrics per month plus caching and multi-credential support. Every successful Semantic Layer API request counts as at least one queried metric, so agent-style workloads should model the consumption line, not just seats.
Do I need dbt Cloud to use the dbt Semantic Layer?
Yes - per dbt's documentation, defining and querying metrics through the Semantic Layer requires a dbt Starter or Enterprise-tier account. dbt Core users can author MetricFlow definitions locally but cannot query them through the APIs or integrations. Colrows runs independently of dbt's platform and connects directly to your warehouse, ingesting dbt model and metric definitions if they exist.
What limitations should I plan for with the dbt Semantic Layer?
Four documented constraints: the mandatory time-spine model you build before time-based metrics work; the single global namespace (two domains cannot both define total_sales without prefixing); a specific list of natively integrated BI tools, with everything else going through JDBC/ADBC/GraphQL; and consumption-based metering of queried metrics on top of seat pricing. None of these is disqualifying for BI consistency - all four matter once AI agents become the consumer.
Can Colrows compile from dbt models without rewriting them?
Yes. dbt models continue to compile in your warehouse; Colrows becomes the runtime layer above them. The Colrows semantic graph maps to dbt model outputs and resolves agent intent against that graph, then emits SQL that runs against the existing dbt-built tables.
How does compile-time governance compare to dbt's access control?
dbt enforces access control at the project, model, and row-level via warehouse policies after queries arrive. Colrows enforces RBAC, ABAC, and row/column-level predicates at compile time, before any SQL is generated. Filtered-out rows are never read; unauthorised queries fail compilation rather than reaching the warehouse.
Further reading
- Deterministic vs Probabilistic Text-to-SQL: A Buyer's Framework - the full accuracy evidence, including dbt's benchmark and the enterprise text-to-SQL data.
- What is a semantic layer? (Pillar guide) - the definitive 2,000-word guide to the category.
- Semantic layer platforms compared - the capability matrix across Cube, Looker, dbt SL, AtScale, ThoughtSpot, and Colrows.
- Colrows vs Cube.js, vs Looker, vs AtScale, vs ThoughtSpot - other competitor comparisons.
- From Metric Stores to Knowledge Machines - why metric layers fall short of what AI needs.