Choose Native Semantic Layers for One Warehouse, Cube for More

Use your warehouse's native semantic layer if one platform holds the data your agents query, and Cube if it doesn't. The published accuracy benchmarks mostly measure data modeling.

By Rajesh Beri·November 10, 2026·16 min read
Share:
A wide wooden records-room table with five unlabelled steel card-index drawers pulled open side by side, one printed ledger page lying across them with a brass ruler marking a single line, in the soft light of a data-off

Illustration generated using AI

Put your metrics in your warehouse's native semantic layer if one platform holds the data your agents will query, and use Cube if it doesn't. Treat every vendor accuracy figure as a claim about data modeling. In dbt Labs' April 2026 benchmark, three extra dbt models lifted plain text-to-SQL on Claude Sonnet 4.6 from 64.5% to 90.0%, with no semantic layer in the path.

Snowflake Semantic Views is the default for a Snowflake estate. Databricks Metric Views is the default for a Databricks estate unless you need per-user row filtering and fast pre-computed answers together, because the docs rule out that combination. The dbt Semantic Layer loses for agents that answer to individual employees: its identity model is built around shared warehouse credentials and its quotas are small. AtScale is the choice for a large Power BI and Excel estate that will accept a private quote.

Option Reaches an agent through Per-user row security Published price (checked Nov 11, 2026) Do not pick it if
Snowflake Semantic Views Snowflake-managed MCP, Cortex Agents, SQL Warehouse policies propagate; OAuth session uses the user's default role No line item for the view; 67 Platform Credits per 1,000 Analyst API messages Your metrics must also serve data outside Snowflake
Databricks Metric Views Genie One MCP, Genie, SQL Unity Catalog grants; no ABAC on the view; no materialization with row policies No line item found; Genie One and Genie Agents free for users until Jan 31, 2027 You need row filters and pre-computed speed together
Cube Hosted MCP, SQL and REST APIs Enforced in the layer, per authenticated user Free tier; $40 and $80 per developer per month; Viewer $20 per user per month Nobody will own policy code; rows are public by default
dbt Semantic Layer Remote or local MCP, JDBC, GraphQL Inherits the warehouse credential; personal credentials per user Starter $100 per user per month, 5,000 queried metrics; Enterprise quote, 20,000 Agents act for hundreds of individual employees
AtScale In-product MCP endpoint, BI protocols Row security objects at query time Quote only, metered on deployed semantic objects You want a price before the first sales call

What a Semantic Layer Does for an Agent

A semantic layer is a governed set of metric, dimension and join definitions that compiles a request for "net revenue by region" into SQL, so the model picks a metric and the layer writes the query. That moves the riskiest step, the join and filter logic, out of the language model.

The failure it prevents is ordinary and expensive. In a case AWS architects presented at dbt Summit, published by dbt Labs on October 27, 2026, an agent summed gross order amounts and returned $14.86 million against a correct $11.36 million, a 30.8% overstatement caused by skipped refunds, cancelled orders and test accounts. The article gives no accuracy figure after the fix.

A layer does not repair the data under it. When one practitioner defined the same Q4 net revenue metric in four layers, Cube returned $3.84 million and the other three $3.81 million, because the models behind them applied exchange rates at different moments. The author's summary: "The semantic layer governed the formula. It did not govern the data it was applied to."


What the dbt and AtScale Benchmarks Prove

Both benchmarks show that context beats raw schema, and neither can tell you which product to buy. Each was published by a company selling the thing that won, and neither scores row-level security.

dbt Labs published its test on April 7, 2026. It uses the ACME Insurance dataset, 11 questions run 20 times each, scored on Claude Sonnet 4.6 and GPT-5.3 Codex. The post carries no conflict disclosure, though its authors work for dbt Labs and it recommends their product.

Setup Sonnet 4.6 GPT-5.3 Codex
Text-to-SQL, original schema 64.5% 64.5%
Semantic Layer, original schema 72.7% 72.7%
Text-to-SQL, 3 models added 90.0% 84.1%
Semantic Layer, 3 models added 98.2% 100.0%

Read the table downward before you read it across. Modeling alone added 25.5 points for Sonnet. The layer then added 8.2. With only 11 questions, one question is worth 9.1 points. The original-schema row also blends two results: on the eight questions within MetricFlow's hop limit, the layer scored 100% against 62.5% for Sonnet text-to-SQL and 51.2% for Codex, and on the other three it scored 0% against 70% and 100%. On questions it can reach, the layer is worth far more than 8.2 points. The three models were also aimed at this test. dbt prompted an LLM "to create as few dbt models as possible to answer all 11 questions," and the post reports no held-out questions, so 90.0% and 98.2% are in-sample results. dbt also notes that text-to-SQL received the entire schema as context, which would not be practical on a large warehouse, so the real gap could be wider than the test shows.

The strongest finding is about how each approach fails. On the original schema the layer scored 0% on questions that needed more joins than MetricFlow allows, because it limits multi-hop joins to two hops and refuses to answer. dbt's framing: "With the Semantic Layer, failure looks like an error message." Text-to-SQL returns a plausible wrong number instead, and your agent has no way to report that.

A rival has already contested the headline. Bodo reports 220 of 220 correct on the same questions using its open-source PyDough, without the three added models. That is a self-reported result from another vendor, run on a rebuilt SQLite copy with a different execution layer, so it is not a replication. It does show that 11 questions cannot separate the approaches.

AtScale's test dates from 2024. The TPC-DS benchmark repository has 40 questions, scored by full-table equality. AtScale's Gemini 1.5 Pro submission scored 92.5% overall, the average of four complexity buckets: 100%, 100%, 100% and 70% on the hardest. The control, given only table schemas and keys, reached 20%. The leaderboard's only entry is AtScale's own, and a schema-only control is the weakest competitor available. The UNICEF test of a generic MCP connector is a useful counterweight: tooling without domain modeling lost to no tools at all.


How Each Layer Reaches an Agent, and Whose Permissions It Uses

Every product here now ships an MCP route, so MCP support should not decide this. What separates them is whose identity runs the query when an agent asks on behalf of a named employee.

Snowflake enforces policies you already have. Row access and masking policies propagate to semantic views, though you cannot set them on the view itself. The managed MCP server uses the connecting user's DEFAULT_ROLE and needs a grant for each tool. Two traps: semantic views use owner's rights, but Cortex Agents need SELECT on both the view and its underlying tables, so a grant that works in a SQL test can fail through an agent. Sample values defined on dimensions are also unmasked in GET_DDL. Check the role an agent inherits before you open this up.

Databricks has a governance gap you should test directly. The Genie One MCP server went GA on September 25, 2026. But ABAC policies cannot be applied to metric views, and you cannot materialize a metric view when it or any source table uses row-level security, column masks or ABAC, since a materialization is computed once under the owner's identity. The pages reviewed do not state which identity an unmaterialized metric view runs under against filtered source tables. A Databricks knowledge base note says ABAC filters on tables reached through views were due to evaluate as the session user by default from July 27, 2026, but it does not mention metric views. Run that test with two users before you commit.

Cube enforces per-user access in the layer and documents how publicly. Its MCP server uses OAuth with PKCE, and the docs state: "Queries respect the same permissions as the rest of Cube, including row-level security." The catch is the default: all rows are public until you write access policies. Its 30 tools also include model-editing and publish actions, limited by role, so scope your agent's account to Viewer.

dbt inherits access from a credential. Its docs say the credentials you configure are used for every request, and that policies tied to those credentials are respected. Per-user access runs through personal access tokens and personal warehouse credentials, and the same page says SSO works for development user accounts but not for production credentials, and that cached results do not carry the security context. OAuth on the remote MCP server is still public beta. For one analytics agent on a shared read role, none of this matters. For 500 employees with different entitlements, it is an identity project.

AtScale applies row security at query time, and an AWS walkthrough from October 20, 2026 shows AgentCore Gateway validating the user's token against the identity provider and AgentCore Identity injecting a credential on the call to AtScale's /mcp endpoint. The post does not say whether that credential belongs to the individual user, and it is one reference architecture on Redshift. Ask for per-user enforcement in the demo.


Native Layers Are Cheaper to Start and Harder to Leave

A native layer costs little to adopt and ties your definitions to one engine. A universal layer costs another platform and keeps them portable. Choose native when you can say honestly that the agent's data will stay in that warehouse for three years.

Portability is improving, though you should treat the converters as untested until you run them. The Open Semantic Interchange spec published its first version on January 27, 2026, under Apache 2, with dbt Labs, Cube, AtScale and Databricks in the working group, and it entered the Apache Incubator as Apache Ossie in July. Its converter repository now lists reference converters for dbt, Cube, Snowflake and Databricks, has no AtScale directory and makes no claim about maturity. Plan as if an exit means reconciling every metric, and run a round trip on your own definitions before you count on one.

Ownership and licensing matter for the universal options too. MetricFlow moved to Apache 2.0 in October 2025, but the Semantic Layer APIs still need a dbt platform plan, and dbt Labs merged into Fivetran on June 1, 2026. Cube's repository defaults to Apache 2.0, which gives you a credible self-hosted fallback.

Who Should Not Buy Each Option

Each of these fails a specific buyer, and the failure is easier to find before signing than after.

Skip Snowflake Semantic Views if Salesforce, Postgres or a second lakehouse will feed the same metrics. It also trails on Looker: the Autopilot docs list Tableau and Power BI imports and do not mention LookML. It is the right default on Snowflake Cortex.

Skip Databricks Metric Views if the agent serves users with different row entitlements on large tables, since those are the views you can't materialize. A shared-entitlement finance or operations agent on Databricks is a good fit. The overview page carries no overall GA or Preview label, so get the status in writing.

Skip Cube if your data team will not write and test access policies, or if you have one warehouse and no plan for a second, since a native layer covers that case without another platform to run.

Skip the dbt Semantic Layer if the agent answers to individuals at scale. Buy it when your metrics already live in dbt, your consumers are a few shared agents and BI tools, and a two-hop join limit fits your model. For employee-facing agents it is the loser here, even though it won the benchmark its maker wrote.

Skip AtScale if you can't justify a sales cycle, or if your estate is not built around Power BI, Excel and other BI protocols. Its open-source converters cover Power BI to SML, dbt to SML and SML to Snowflake, and no Tableau or LookML path was announced.


What It Costs at 60,000 Agent Questions a Month

Normalize to one workload: 500 employees, 5 metric developers, 2,000 agent questions a day (60,000 a month), two metrics per question, US region. Prices were checked on each vendor's live page on November 11, 2026, and they exclude warehouse compute, which every option here pushes to your warehouse.

Option Calculation Monthly cost before compute
Snowflake, Analyst API 60,000 × 67 Platform Credits per 1,000 messages × $3.00 (Enterprise, AWS US East 2) $12,060
Snowflake, via Cortex Agents 3 model calls per question, 8,000 input and 500 output tokens each, Sonnet 5.5 at 1.30 and 6.50 AI Credits per million, $2.00 per AI Credit (global routing) About $4,914 (assumed token counts); about $5,405 at the $2.20 regional routing rate
Cube Premium 5 × $80 + 500 Viewer × $20 + dedicated deployment at $1.20 per hour $11,276 (excludes caching workers)
dbt 120,000 queried metrics against 5,000 on Starter, 20,000 on Enterprise Quote required; no public overage rate
Databricks Genie One and Genie Agents usage by users is free until January 31, 2027; the page does not say what they cost users after that $0 for users today; service principals billed from the first call
AtScale Metered on deployed semantic objects; agent usage is not billed per query Quote required

These results should change your procurement plan. Snowflake's own table prices the older Analyst API far above the Agents route at these assumptions, so confirm which one your agent uses. Cube's cost is almost entirely Viewer seats, because its MCP server requires a Viewer role or higher, and its pricing page does not say how agent access for service accounts is charged. On Databricks, budget now for the free period ending January 31, 2027, and note that a single service principal gets no allowance and no per-user identity.

What Moving Metrics Out of LookML, Power BI or Tableau Costs

No converter finishes this job, and no vendor publishes a credible hours-per-metric figure, so scope it by counting what will not convert. Every migration needs a reconciliation run against the old numbers.

From LookML, dbt's converter warns that it "can only help with the migration and leaves many manual steps to the user," and it requires dbt-core 1.5. MetricFlow rejects fan-out joins, where Looker handles them with symmetric aggregates, so some explores will need remodeling. Cube's lkml2cube is the closest fit, though only its views command brings joins across.

From Power BI, Snowflake's ingestion went GA on August 18, 2026 and handles straightforward measures. Its unsupported list is where the budget goes: time intelligence such as TOTALYTD and SAMEPERIODLASTYEAR, RANKX, TOPN, percentiles, calculation groups, and measures saved in reports. Export your DAX and count those functions before you estimate anything.

From Tableau, Autopilot reads workbook and data source files, including calculated fields. Treat level-of-detail expressions as manual until your own test proves otherwise.

Run This Test Before You Believe Any Accuracy Number

Run a bake-off on your own schema, with questions the vendor never sees, and write down the scoring rule before the first run.

  1. Collect 40 real business questions from dashboards and support tickets. At 40, one question is worth 2.5 points, which is still coarse.
  2. Have the metric owners write the correct answers, then freeze 20 questions as a held-out set that nobody models against.
  3. Include questions your data cannot answer, and score a refusal as correct on those.
  4. Score three arms: text-to-SQL on the raw schema, text-to-SQL on the modeled schema, and the layer. Without the middle arm you can't separate the product from the modeling. dbt's test has that arm and AtScale's does not.
  5. Run each question 20 times, matching dbt's protocol, and score by result equality.
  6. Report wrong answers and refusals separately. A wrong number that looks right costs more than an error message.
  7. Repeat the held-out set as three employees with different row entitlements, through the MCP path, and diff the results. Any leak fails the product.

Grab's five-month run of analytics agents found metric context to be the ceiling, which is the variable this test isolates.


The Criteria That Predict Regret

Regret on this purchase comes from three things, in this order: an identity model that can't represent your entitlements, a metric estate that converts worse than the demo suggested, and quotas sized for dashboards being hit by agents.

The answer changes in specific cases. If a second warehouse is funded and dated, move from native to Cube. If every agent runs on a shared service identity and entitlements don't vary, dbt becomes a reasonable choice and its modeling workflow is the best of the group. If your definitions already live in Power BI and users ask from Excel, price AtScale and also Snowflake's XMLA path. If your governed metrics number under 20, skip the purchase and start with modeled tables, since that is where most of the published accuracy gain came from.

What to Do Next

This Week:

  1. Write down where the agent's data lives today and where your roadmap puts it in three years.
  2. Ask your security lead whether answers must differ by employee. If they must, put the dbt Semantic Layer and Databricks Metric Views through the permissions test first.
  3. Export LookML, DAX and Tableau calculated fields, and count metrics by function used.

This Month:

  1. Run the seven-step test on your top two candidates, including the three-employee permissions check.
  2. Get written answers on GA status, identity for unmaterialized queries, and overage rates.

Before Q1 Close:

  1. Model your top 20 metrics, reconcile them against finance's numbers, and name an owner for each.
  2. Reforecast Databricks costs for the end of Genie's free period on January 31, 2027, or Snowflake's Analyst API against the Agents route.

The Bottom Line

Native layers are the default because the row and masking policies you already maintain sit next to the data. Cube is the better purchase once your data crosses platforms. Whichever you choose, spend the first month on the three-arm test and the 20 metrics finance signs off on, because modeling produced most of the accuracy gain in the benchmark dbt Labs published.

Book the three-employee permissions test before you book the vendor demo.

Continue Reading

Share:

Frequently Asked Questions

Which semantic layer is best for AI agents?

Use Snowflake Semantic Views or Databricks Metric Views if one platform holds the data your agents query, and Cube if your data spans warehouses. The dbt Semantic Layer suits a few shared agents better than agents acting for hundreds of individual employees.

Do semantic layers improve text-to-SQL accuracy?

Yes in published tests, though modeling does most of the work. In dbt Labs' April 2026 benchmark on 11 questions, three added dbt models lifted Sonnet 4.6 text-to-SQL from 64.5% to 90.0%, and the Semantic Layer added another 8.2 points. dbt Labs sells the product it tested.

Does the dbt Semantic Layer support row-level security per user?

It inherits access from the warehouse credential used for each request. Per-user access needs personal access tokens and personal warehouse credentials, dbt's docs say SSO works for development user accounts but not production credentials, and cached results do not carry the security context.

Can Databricks Metric Views use row filters?

Databricks documents that ABAC policies cannot be applied to metric views, and that a metric view cannot be materialized when it or a source table uses row-level security, column masks or ABAC. Test how an unmaterialized view behaves with two users who have different entitlements.

How much does a semantic layer cost for agents?

At 60,000 agent questions a month, Snowflake's Analyst API comes to about $12,060 before compute, and Cube Premium to about $11,276 with 500 Viewer seats. dbt needs a quote at that volume, AtScale publishes no prices, and Genie One and Genie Agents usage by Databricks users is free until January 31, 2027.

How should I test a semantic layer before buying?

Use 40 of your own business questions, freeze 20 as a held-out set, and score text-to-SQL on the raw schema, text-to-SQL on the modeled schema, and the layer. Run each 20 times, report wrong answers and refusals separately, and repeat as three employees with different row entitlements.

Newsletter

More on MCP & Interop, every Sunday

The week's enterprise AI news, MCP & Interop included, in one Sunday email.

Weekly, free. Unsubscribe any time. Privacy

Latest Articles

View All →