The best semantic layer tools in 2026, compared

If you already model in dbt, the dbt Semantic Layer is the best place to start in 2026, and Cube is the stronger choice once you need caching and per-user access rules across many tools and agents. Teams that run everything on Snowflake or Databricks can now get a long way with the warehouse's own semantic views, without buying another tool.

The other six tools on this list each win in a narrower case: AtScale for large Excel and Power BI estates, Honeydew for a Git-based layer on Snowflake, and Looker, Power BI, Omni and GoodData.AI when one BI or analytics platform is where people already work.

If you're new to the idea, start with what a semantic layer is and why AI agents need one. This post assumes you've decided you want one and compares the ten tools you're most likely to shortlist.

Summary: We compared ten semantic layer tools on where definitions live, warehouse support, agent and MCP access, row-level security, caching, price and lock-in, using each vendor's documentation as of 13 November 2026. The best pick depends mostly on where you already model and how many tools need the same metrics.

The ten tools at a glance

Checked on each vendor's documentation and pricing page on 13 November 2026. Prices are list prices in US dollars, billed yearly where the vendor says so.

We picked the ten tools that appear most often in comparisons and buyer shortlists this year, and read each one's own documentation rather than other comparison posts. Weld doesn't sell a semantic layer, so none of these is ours. We left out BI tools whose model mainly serves their own dashboards, such as Tableau Semantics, ThoughtSpot, Sigma and Lightdash, query engines such as Dremio, and retired products such as Transform, which dbt Labs bought in 2023 and folded into the dbt Semantic Layer.

The short version, by situation. Each one is explained under who should pick what.

Where the definitions live

The biggest difference between these tools is where your metric definitions are stored, because that decides who can edit them and which tools can read them.

• In your transformation project. The dbt Semantic Layer keeps metrics in YAML next to your dbt models, powered by MetricFlow. Metrics go through the same pull requests, tests and CI as the models they're built on. dbt Labs completed its merger with Fivetran in June 2026, and dbt v2 became generally available in September.
• In a standalone service. Cube models are YAML or JavaScript in their own repository. AtScale uses SML, its own YAML language, published under Apache 2.0. Honeydew keeps one YAML file per object in Git.
• In the warehouse. Snowflake semantic views are schema objects, created with CREATE SEMANTIC VIEW or from YAML. Databricks metric views are YAML stored as views in Unity Catalog and queried with MEASURE().
• In a BI tool. Looker's LookML lives in a Git project. Power BI models can be saved as TMDL, a text format with one file per object, built for source control. Omni models are YAML in Git. GoodData.AI uses a logical data model and MAQL metrics, edited in the UI or as YAML through its CLI.

Every option now supports Git in some form, so the real question is who owns the metrics. If analytics engineers own revenue, the dbt project is the natural home; if a BI team does, LookML or a Power BI model may be.

Whichever you choose, keep the semantic layer thin. Trials, currency conversion and deduplication belong in tested models underneath, and the semantic layer only says how to aggregate and slice them. The MRR walk-through in our semantic layer guide shows the split.

Warehouse support

Warehouse-native options lock the definitions to one warehouse, and every other tool here works across several. That matters most if you run two warehouses, or might move.

• One warehouse only: Snowflake semantic views and Databricks metric views.
• Several warehouses: the dbt Semantic Layer supports Snowflake, BigQuery, Databricks, Redshift, Postgres and Trino. Cube connects to most warehouses and databases, including ClickHouse and Microsoft Fabric. AtScale covers Snowflake, Databricks, BigQuery, Redshift and Postgres. Honeydew started on Snowflake and added Databricks and BigQuery in January 2026.
• BI tools: Looker and Omni query the databases you connect them to. Power BI can import from any number of sources, but its semantic model lives in Power BI and Fabric.

On BigQuery there's no warehouse-native semantic view, and Google's own answer is Looker. Looker's Open SQL Interface lets JDBC tools query LookML models, but only on a BigQuery connection, with SELECT only and no joins or subqueries.

Which metrics each tool can express

Simple sums and counts work everywhere. The differences show up in the metrics finance actually asks for: this month against last month, a running total, a conversion rate between two events, or a ratio of two numbers at different grains.

• dbt Semantic Layer: five metric types: simple, ratio, cumulative, derived and conversion. Derived metrics take an offset_window, which is how you compare a month with the one before.
• Cube: multi-stage measures with rolling_window for running totals and to-date values, and time_shift for period over period. Multi-stage measures aren't served from pre-aggregations yet, so they always run on the warehouse.
• Looker: a period_over_period measure type for previous period, difference and relative change, on BigQuery, Snowflake and Redshift connections.
• Snowflake: semantic views accept window function metrics, and level of detail expressions arrived in Preview on 2 November 2026.
• Databricks: metric views support window measures with trailing, leading and offset ranges, listed by runtime version on the feature availability page.
• Power BI: DAX has the deepest time intelligence of the group, at the cost of a language only Power BI and Analysis Services speak.

Before you commit, write your three hardest metrics in each tool on your shortlist. A tool that can't express net revenue retention or a trial-to-paid conversion rate pushes that logic back into SQL, where each dashboard and agent will write it again.

Agent and MCP access

Every tool on this list now gives AI agents a way in, and the differences are in status and in what the agent is allowed to do.

Two things matter more than the tool count. First, can the agent only read? Cube's and Honeydew's servers also include tools that edit the model and open pull requests, which is useful for building a model with an agent and something to switch off for a business user's agent. AtScale and Fabric IQ are read-only by design, and Microsoft ships model editing as a separate Power BI Authoring MCP server.

Second, does the agent query as the person asking? Fabric IQ only accepts delegated user sign-in, not a service principal, so Power BI's security roles always apply. Cube says its MCP queries "respect the same permissions as the rest of Cube, including row-level security", and Omni runs MCP queries with the user's own permissions. That leads to the next criterion.

Row-level security and governance

Access rules are enforced in one of two places: in the semantic layer, based on who is asking, or in the warehouse, based on the credential the semantic layer uses. For agents, the first is easier to get right, because one shared credential can't tell a sales lead from the CFO.

Rules in the semantic layer:

• Cube: access policies with row filters, member masking and group rules, driven by the user's security context or Cube Cloud user attributes.
• Looker: access_filter on a user attribute.
• Power BI: roles with DAX row filters, plus object-level security for tables and columns, enforced through Fabric IQ MCP too.
• Omni: access_filters from user attributes, and access_grants for which topics and fields a user sees.
• GoodData.AI: user data filters written in MAQL, and workspace data filters for multi-tenant setups.
• AtScale: row security objects in the model, with optional impersonation that queries the warehouse as the end user.
• Honeydew: domain filters in the layer, or rules in the warehouse or the BI tool; it supports all three.

Rules in the warehouse:

• dbt Semantic Layer: it queries with a configured warehouse credential, and "all access policies set in the data platform for this credential will be respected" (dbt docs). Starter allows one credential per project, Enterprise several, for example one per team.
• Snowflake semantic views: row access and masking policies sit on the base tables and carry through; they can't be set on the semantic view itself.
• Databricks metric views: standard Unity Catalog permissions control who can query the view, but attribute-based row filters and column masks can't be applied to metric views.

Warehouse-enforced rules are a good fit when every user or agent already signs in to the warehouse as themselves. When an agent runs on a shared service account, you need rules the semantic layer applies per user, or one credential per audience.

Caching and performance

Most of these tools speed up popular queries by pre-aggregating them, and the main difference is where the pre-aggregated data is stored.

• Cube stores pre-aggregations in Cube Store, its own cache, and routes matching queries to them. It has the most built-in caching on this list, which suits embedded analytics with many concurrent users. In Cube Cloud, Cube Store caching starts on the Starter plan and is billed per worker hour.
• AtScale and Honeydew build aggregate tables in your warehouse and route queries to them. AtScale rebuilds them incrementally on Snowflake, Databricks, BigQuery and Redshift, and checks a user's permissions before serving an aggregate, because the aggregate tables don't carry the security rules.
• Snowflake made semantic view materializations generally available on 11 November 2026, so common metric and dimension combinations can be pre-computed.
• Databricks can materialize metric views on serverless pipelines with incremental refresh, but not when the view or its sources have row filters or column masks.
• Looker has aggregate awareness, persisted as derived tables. Power BI has import mode, which copies data into the model, alongside DirectQuery. GoodData.AI has FlexCache and aggregate awareness for tables you build.
• The dbt Semantic Layer has result and declarative caching, listed on the Enterprise plans, and otherwise sends every query to the warehouse.

Notice the trade-off on Databricks and AtScale: caching and row-level rules don't combine freely. If you need both, test them together before you commit.

Pricing as of November 2026

Four of the ten publish prices, and the rest are quote-only.

To make that concrete, take a team of three analytics engineers who maintain the metrics, at list prices:

• dbt Starter: 3 × $100 = $300 a month, with 5,000 queried metrics a month included.
• Cube Starter: 3 × $40 = $120 a month, plus one small Cube Store worker running all month at $0.15 an hour, about $110, so roughly $230.
• Honeydew Lite: 3 × $20 = $60 a month plus the platform fee from $500, so from $560.

Viewers add to Cube and Honeydew bills per seat, while dbt counts queried metrics instead, so the order changes as more people and agents ask questions.

The licence is usually the smaller part of the cost. Every metric needs an owner and every change a review, and that time is the same whichever tool you pick. With warehouse-native options you pay no licence, but every query and every agent question runs on warehouse compute, so watch the bill when agents start asking questions all day.

Open source and lock-in

Lock-in is lower than it was a year ago, because the industry now has a shared format for semantic definitions. The Open Semantic Interchange, started in September 2025, is now Apache Ossie, an incubating Apache project with more than 50 member organisations and a YAML spec on GitHub.

Support so far:

• dbt 1.12 reads and writes Ossie documents: files in an osi/ folder are parsed into the project, and an osi_document.json is written to target/. MetricFlow itself is Apache 2.0.
• Snowflake can create a semantic view from Ossie YAML and export one to it, both in Preview, and the export drops some details such as labels and data types.
• Cube has Ossie import and export in Preview, switched on by Cube support. Cube's core is Apache 2.0.
• Honeydew has a two-way Ossie converter.
• Databricks, AtScale, GoodData and Omni are Ossie members, but we found no import or export in their products yet. Databricks is also open-sourcing metric views into Apache Spark.
• Looker and Power BI: no Ossie support documented.

Two cautions. The spec is young, and versions differ: dbt accepts Ossie 0.1.0 and 0.1.1, while Honeydew tracks a 0.2.0 draft. And a format only moves the definitions. Access rules, caching settings and the integrations built around a layer still have to be rebuilt if you switch.

There are simpler escape hatches too: Honeydew and GoodData.AI read dbt manifests, and Cube and Omni import from dbt as well.

Using two layers together

Many teams end up with two layers, and that's fine as long as each metric is defined in one of them.

• dbt and Cube. Cube's cube_dbt package generates Cube models from your dbt project, so dbt owns the models and Cube adds caching, access rules and the APIs on top.
• dbt and a BI tool. Power BI, Tableau, Excel, Google Sheets, Hex and Omni can query the dbt Semantic Layer directly, so the BI tool shows dbt's metrics instead of redefining them.
• The warehouse and a BI tool. Omni imports Snowflake semantic views and Databricks metric views, and Databricks is adding Power BI publishing for metric views.

The setup to avoid is the same metric defined in two layers, because that's the disagreement you bought a semantic layer to end.

How to test a shortlist

A two-week trial with real metrics tells you more than any comparison table, this one included. Pick two tools and build the same three metrics in each:

1. A plain count, such as active customers. It shows how much setup the tool needs before the first number.
2. Revenue with exclusions, such as MRR without trials and refunds, compared month over month. It tests how the tool expresses the metrics finance cares about.
3. A restricted metric, such as pipeline by region, where a sales lead should only see their own. It tests the access rules, through a dashboard and through an agent.

Then ask an agent the same ten questions through each tool's MCP server, and compare the answers with what finance reports. Note how long each query takes and what it costs in warehouse compute. Those numbers decide more than a feature list.

Who should pick what

• You model in dbt and want agents and dashboards on the same metrics: the dbt Semantic Layer. Budget for Starter at least, and plan for row-level rules in the warehouse.
• You need per-user access rules, caching, or metrics in a customer-facing product: Cube. It runs on any warehouse and has the most built in.
• Everything is on Snowflake: semantic views first, now with materializations and a GA MCP server. Add a separate layer only when tools outside Snowflake need the same metrics.
• Everything is on Databricks: metric views with Genie, as long as you don't need attribute-based row filters on the views themselves.
• A large Excel and Power BI estate on a cloud warehouse: AtScale, which speaks to those tools natively and pushes aggregates into the warehouse.
• A small team on Snowflake that wants a Git-based layer with published prices: Honeydew.
• One BI tool is where most people already work: keep its model (LookML, Power BI or Omni) for dashboards, and add a separate layer only when agents or other tools need the same definitions.
• Analytics embedded in your own product, across many tenants: GoodData.AI or Cube.

Where Weld fits

Weld isn't a semantic layer. It runs the foundation they all sit on: it syncs Stripe, HubSpot, your product database and 300+ other sources into your warehouse, runs the SQL or dbt models your metrics are built on, and gives agents an MCP server to check that the data behind a number is fresh.

That foundation decides more about whether a metric is right than the choice of semantic layer does. A perfectly defined mrr metric still returns the wrong number if Tuesday's Stripe sync failed.

OMHU, a Weld customer, runs this setup: Weld syncs Shopify, payment providers and marketing tools into BigQuery, dbt models the data, and Cube defines the metrics for reporting, finance and the team's AI agents in Slack. Their customer story walks through it, and the agent context stack shows where the semantic layer sits among the other layers agents need.

If you can't decide, run the three-metric test on the tool that matches where you model today. Our forward deployed engineers can set up that first domain with you.

FAQ