14 Best Semantic Layer Tools for BI and AI Agents in 2026

---

The best semantic layer tools for 2026 fall into four categories: pure semantic layers (dbt Semantic Layer, Cube, AtScale, Honeydew), warehouse-native semantic views (Snowflake Semantic Views, Databricks Metric Views), BI-native semantic models (Looker/LookML, Power BI semantic models, ThoughtSpot Spotter Semantics, GoodData, Sigma data models, Tableau Semantics, MicroStrategy ONE), and the context layer that governs how AI agents consume definitions from all of the above. The BI-native category is the one that grew: the major BI platforms have each shipped a semantic layer, so “which BI tool do we already own” is now a semantic-layer question too. Each tool scores differently on three AI-agent readiness dimensions: API access an agent can call (SQL, GraphQL, REST, or MCP), governance signals an agent can read (lineage, ownership, certification status), and metric definitions an agent can cite in its answers. The comparison table below scores each tool across these dimensions. If your stack only serves BI dashboards, a pure semantic layer is sufficient. When AI agents enter the picture, whether that is Snowflake Cortex Analyst, Databricks Genie, or an MCP-connected copilot, you also need the governance layer that wraps those metric definitions for agent consumption.

Four architectural categories of the modern semantic layer stack explained. Image by Atlan.

---

Quick facts: semantic layer category map

---

Semantic layer vs context layer vs metadata layer: what’s the difference?

A semantic layer defines what metrics mean. A context layer governs how AI agents use those definitions. A metadata layer catalogs what data exists.

A semantic layer defines metrics. It tells your BI tool what “monthly active users” means in SQL or YAML and serves that definition to dashboards and embedded analytics. What it doesn’t do: govern who can use that definition, trace where it came from, or expose it to AI agents with an audit trail.

A context layer governs how AI agents and analysts use those metric definitions in production. It binds them to lineage, ownership, business glossary terms, and access policies, then exposes that governed context to MCP-connected agents and other AI-native interfaces. It complements the semantic layer underneath, adding the governance and audit trail that metric computation on its own was never built to carry. See context layer vs semantic layer for the full distinction, and agent context layer architecture for a production walkthrough.

A metadata layer is the catalog underneath both. It indexes what data exists, where it lives, and who owns it. Active metadata is what makes that catalog queryable by AI agents and analysts. It does not define what metrics compute or govern how agents consume them.

The three layers are complementary, not substitutes. Most “all-in-one” pitches collapse them into one product name. The confusion costs money during evaluation.

---

What are the best semantic layer tools for AI agents specifically?

Semantic layer tools that serve AI agents well combine three properties: API access an agent can call (SQL, GraphQL, REST, or MCP), governance signals an agent can read (lineage, ownership, certification), and metric definitions an agent can ground its answers in. Specific tool readiness varies along these axes. The table below scores each tool.

AI-agent readiness table

dbt Semantic Layer, Cube, and the warehouse-native options deliver the API surface. A context layer adds what an AI agent needs beyond the definition itself: who certified the metric, where its inputs came from, and whether the asking user is allowed to see them. Snowflake Intelligence + Atlan deliver 3x query accuracy across a 522-query enterprise benchmark, at 95%+ reliability when grounding text-to-SQL in enriched semantic and context metadata instead of schema alone. See the Atlan MCP Server for the MCP delivery pattern.

---

How should you choose a semantic layer for your stack?

Choose by use case, not feature checklist. For BI metric consistency, pick a code-first semantic layer (dbt Semantic Layer, Cube, Honeydew) or your warehouse’s native option (Snowflake Semantic Views, Databricks Metric Views). For AI-agent governance across multiple semantic layers, add a context layer on top to unify governance, lineage, and access context across them.

Are you a dbt shop standardizing metrics across BI?

dbt Semantic Layer (MetricFlow) is the recommended pick. If the dbt platform account requirement is a constraint, Cube is the backup: same code-first workflow, no dbt dependency. Evaluate Cube early if your org runs global or multi-cloud deployments.

Are you committed to one warehouse and want native semantics?

Snowflake-committed shops should evaluate Snowflake Semantic Views first. Databricks shops should evaluate Databricks Metric Views first. Warehouse-native definitions do not move cleanly to other warehouses, so this choice only makes sense when warehouse commitment is firm. Honeydew is the third option for Snowflake shops that want the same pushdown execution model while keeping definitions in Git rather than inside the warehouse’s own object system; Databricks and BigQuery support is still in beta.

Do you need a headless semantic layer for embedded analytics or AI apps?

Cube is the recommended pick. Its multi-API surface lets embedded analytics, AI copilots, and BI tools query the same metric definitions simultaneously. AtScale is the backup for enterprises with existing OLAP and Excel/Power BI investments that need MDX support.

Are you a large enterprise with a mixed BI estate (Power BI, Excel, Tableau)?

AtScale is the default. MDX support and Semantic Aggregation, AtScale’s term for resolving queries against optimized aggregates instead of scanning raw fact tables, make it the standard choice for Fortune 500s with legacy OLAP commitments. MicroStrategy ONE is a viable backup for organizations with an existing MicroStrategy investment.

One wrinkle worth planning for: two of the tools in that estate now define metrics themselves. Power BI has its semantic models and Tableau has Tableau Semantics. A universal layer above them does not remove those definitions, it competes with them, so decide early which layer owns a given metric and which one only reads it. Excel is the consumer that still has no opinion of its own.

Are you building AI agents that need to query metrics across multiple semantic layers?

Atlan, as the context layer on top of whichever semantic engine you choose. The semantic layer handles metric definitions. The context layer wraps them in governance and exposes them through MCP so agents inherit ownership, glossary terms, and access controls along with the number. Without that added context, AI answers may still be accurate on paper but harder to govern, audit, and trust in production. See how to build an AI-ready semantic layer.

Match your buyer profile to the right semantic layer tool in 2026. Image by Atlan.

---

The three walls of semantic-layer-only buying

Semantic layers without governance fail in production for three repeatable reasons. Name the walls before the procurement cycle and the buying frame changes.

• Wall 1: Ungoverned answers. A semantic layer returns a number; it does not certify it. Agents grounded only in metric definitions can produce the right value with no record of who owns it, where it came from, or who’s allowed to see it. Auditors and exec consumers cannot trust the answer.
• Wall 2: Lineage gap at inference. Definitions live in the semantic layer; lineage lives in the catalog. At agent inference time, the two are not joined. The agent cites the metric but cannot cite the upstream source.
• Wall 3: Cross-tool drift. Two semantic layers (e.g., dbt SL plus Snowflake Semantic Views) drift in definitions when each team owns its own DSL. Without a context layer wrapping both, the same metric returns different numbers in different tools.

Semantic layers without governance is the documented failure mode behind each wall.

---

Which 14 semantic layer tools made the 2026 shortlist?

Two criteria decide inclusion: category honesty and AI-agent readiness. A tool qualifies if it ships a semantic layer that defines metrics, and if a BI tool or an AI agent can consume that definition through a documented surface. Nothing else gates the list.

Apache Ossie participation is not one of those criteria. It used to be, and that was a mistake: the list has always included tools whose vendors are not in the working group, so the stated criterion contradicted the list itself. Ossie membership is now reported per tool in the table below as a portability signal you can weigh, and the reporting is checkable against the working-group roster.

That reporting produces an asymmetry worth pausing on. Salesforce sits in the Ossie working group, so Tableau Semantics carries the standard. Google does not, so Looker and LookML do not, despite Looker having originated this whole category. Anyone using Ossie membership as a procurement filter should know it cuts across vendor reputation rather than along it.

On those two criteria, fourteen tools qualify: dbt Semantic Layer, Cube, AtScale, Honeydew, Atlan (as the context layer), Snowflake Semantic Views, Databricks Metric Views, Looker and LookML, Power BI semantic models, ThoughtSpot Spotter Semantics, GoodData, Sigma data models, Tableau Semantics, and MicroStrategy ONE.

The order groups by category before it ranks. Pure semantic layers come first, because that is the decision you make before any of the others. Then the context layer that wraps them, then warehouse-native views, then BI-native models. Inside each category, tools are ordered by AI-agent readiness and ecosystem breadth, judged on documented surfaces rather than on roadmap.

That ordering puts Atlan fifth, and it earns fifth the same way everything else earns its slot. Atlan is the wrong tool to open an evaluation with. Pick the semantic layer first; the context layer is the decision after it, not before. Applying the same rule inside the BI-native block pushes Tableau Semantics to thirteenth, below tools with smaller install bases, because its agent surface is the least documented of the group. Both placements come from the criterion, not from preference.

The BI-native category runs to seven entries because the BI platforms all shipped semantic layers while the category was being written about as though they had not. An earlier version of this page listed three. That was a gap in the list, not a judgment about the four that were missing.

---

All 14 tools at a glance. Grouped by category, then ordered by AI-agent readiness and ecosystem breadth. The Ossie column reports working-group membership; it does not gate the list.

---

1. dbt Semantic Layer: the code-first, vendor-neutral standard

If your analytics engineers already own transformations in dbt, the Semantic Layer extends that same workflow into metric definitions. MetricFlow runs underneath. Definitions live in version-controlled YAML next to the models they reference. dbt Labs published the first version of the Apache Ossie specification with its partners on 2026-01-29, which makes those definitions portable across BI tools and AI agents rather than locked to one vendor’s syntax. For dbt shops, this is the safest default.

Who it’s for: dbt-committed teams extending their transformation workflow to metrics. Most useful when analytics engineers own metric definitions.

Key capabilities:

• MetricFlow DSL for defining measures, dimensions, entities, and time-grain logic in YAML
• Native consumption via JDBC, ADBC, GraphQL, and a Python SDK, plus integrations with Hex, Mode, Lightdash, Tableau, Power BI (the broadest pre-built BI integration ecosystem on this list)
• Apache Ossie support from dbt v1.12: Ossie documents live in an osi/ directory and coexist with native dbt semantic models
• MCP-compatible definition export for AI-agent consumption

Limitations:

• A dbt platform Starter or Enterprise-tier account is required to define and query Semantic Layer metrics. The free Developer tier does not include it
• Definitions live in code, not a UI. Adoption is harder when analysts (not engineers) own metric definitions

As Apache Ossie reaches broader adoption, MetricFlow definitions will move across warehouses and AI systems without rewriting. dbt’s docs are strict on versions: an Ossie document must declare 0.1.0 or 0.1.1, and any other version string raises a parse error.

How Atlan extends dbt Semantic Layer: Atlan natively ingests dbt semantic models and enriches them with ownership, lineage, and quality signals. AI agents querying via the Atlan MCP Server get the dbt definition plus the surrounding governance context. See the Atlan dbt Semantic Layer integration.

Pricing: Part of the dbt platform, formerly dbt Cloud. Developer is free but excludes the Semantic Layer; Starter is $100 per user per month and lists “dbt Semantic Layer basic” with 5,000 queried metrics a month; Enterprise and Enterprise+ are custom and list governed metrics with caching at 20,000 queried metrics a month.

---

2. Cube: the universal semantic layer with an open-source core

Cube describes itself as the agentic analytics platform for business intelligence and embedded analytics, built on an open-source semantic layer. One metric definition, four Core Data APIs (SQL, DAX, REST (JSON), and GraphQL), and a core that engineering teams can self-host or run on Cube Cloud. The result is a semantic backbone that a BI tool, a product dashboard, an AI copilot, and a third-party integration can all query at the same time without rewriting the metric in each place. That’s why Cube shows up frequently in product analytics, customer-facing embedded dashboards, and AI applications.

Who it’s for: Engineering-led data teams building embedded analytics, customer-facing dashboards, or AI applications that need one semantic API serving many consumers.

Key capabilities:

• Multi-API surface: SQL, DAX, REST (JSON), and GraphQL from one metric definition
• Open-source core (Cube Core) plus managed cloud option (Cube Cloud)
• Pre-aggregation engine that caches and materializes query results for sub-second embedded analytics response times
• An MCP server with 30 documented tools reaching query and discovery, dashboard authoring, data-model editing, committing and publishing changes, and pre-aggregation builds
• Apache Ossie participation, and its own Workbooks, Dashboards, Charts, Analytics Chat, and Slack Agent on top of the semantic layer
• Strong embedded analytics SDK story for SaaS products

Limitations:

• Engineering-heavy setup compared to BI-native semantic models
• Smaller ecosystem of pre-built BI tool integrations than Looker or dbt SL
• Self-hosted complexity when not on Cube Cloud
• Several surfaces are plan-gated: the MCP server is Premium and Enterprise only, the dbt integration’s pull direction is Premium and above, and dbt push is still in preview

The open-source core (cube-js/cube on GitHub) carries 20.9k stars and 2.1k forks as of 2026-09-18, and is auditable and community-extensible. Full API reference in the Cube documentation.

Adjacent layer note: Cube is the universal semantic layer; Atlan is the context layer that wraps semantic engines and binds definitions to lineage, ownership, and glossary terms, then surfaces them for AI-agent governance. Apache Ossie is the emerging interoperability standard between them.

Pricing: Cube Core is open-source. Cube Cloud runs a free tier, Starter at $40 and Premium at $80 per developer per month, and custom Enterprise contracts. On Premium and above, Explorer seats are $40 and Viewer seats $20 a month, so a wide rollout costs more than the per-developer line suggests.

---

3. AtScale: the enterprise universal semantic layer

Most Fortune 500 data estates didn’t start with a modern warehouse. They started with Excel models querying OLAP cubes via MDX, often a decade before the term “semantic layer” took hold. AtScale’s job is to keep that interface alive while bolting on SQL, DAX, REST, and Python so the same metric serves Power BI, Tableau, ThoughtSpot, and modern custom apps from one definition. The automatic aggregate generation is what makes it scale to billion-row fact tables without manual tuning.

Who it’s for: Large enterprises with significant Power BI, Excel, and MDX investment that want a single semantic layer across the BI estate.

Key capabilities:

• MDX, SQL, DAX, REST, Python API surfaces from one definition layer
• Automatic aggregate generation: builds and manages materialized aggregates without manual tuning
• AI-Link, a Python package giving data science and ML workflows programmatic access to the semantic layer. The AtScale MCP server, not AI-Link, is the agent surface
• Apache Ossie working-group membership for vendor-neutral definition portability
• Mature enterprise security and governance controls

Limitations:

• Enterprise pricing. Not suited for smaller teams or early-stage data orgs
• Heaviest natural fit for organizations with an OLAP-cube heritage. More configuration overhead than headless options

How Atlan extends AtScale: Atlan layers operational metadata, including lineage, glossary terms, ownership chains, and access controls, around AtScale definitions through context-layer and Ossie-aligned patterns.

Pricing: Enterprise pricing. Contact AtScale.

---

4. Honeydew: metrics as code, computed where the data already sits

Honeydew is the name most Snowflake teams on this list have not evaluated yet. Entities, relations, attributes, metrics, and filters live in YAML held in Git, and the expressions inside them are plain SQL rather than a bespoke DSL, so an analytics engineer who can write a window function can write a metric on day one. Nothing is extracted or copied: Honeydew reads schema metadata and runs the generated SQL inside the customer’s own warehouse, which keeps compute, cost attribution, and row-level access under existing controls. Snowflake is the production path, including a Native App from the Snowflake Marketplace that runs inside the customer’s account. Databricks and BigQuery are both in beta.

Who it’s for: Snowflake-committed teams consolidating BI logic that has drifted across Power BI, Tableau, and Excel, and teams that want AI agents querying a governed model instead of writing raw SQL against tables.

Key capabilities:

• YAML models in Git with GitHub, GitLab, Bitbucket, and Azure DevOps integration, plus CI/CD through GitHub Actions
• Query surfaces from one definition: a Trino-backed SQL interface, a GraphQL API, an XMLA endpoint that Excel connects to directly, and JDBC/ODBC
• A hosted MCP server exposing more than 60 tools for discovery, modeling, and query execution, with documented clients including Snowflake Intelligence, Claude Code, Cursor, and VS Code
• Snowflake Semantic Views can be added as a source, with Honeydew extending the Cortex semantic model in that view across the wider org model
• Founding participation in Open Semantic Interchange, now incubating at Apache as Ossie, with bidirectional import and export of Ossie models
• SOC 2 Type II, enterprise SSO, and row-level security inherited from the warehouse

Limitations:

• Snowflake is the only generally available warehouse. Databricks and BigQuery are beta and gated behind a support request
• No first-party Python SDK. Notebook access runs through the third-party Trino client against the SQL interface, and the documented API surface is GraphQL rather than REST
• The smallest vendor on this list by headcount, with a correspondingly thin third-party integration ecosystem next to dbt Semantic Layer or Cube
• No Atlan connector today, so definitions do not flow into the Enterprise Data Graph automatically

Snowflake Ventures invested in May 2025 and published Pizza Hut as a reference customer: reports delivered four hours earlier, insight development 50% faster, and a 30% reduction in cost and engineering effort. The company came out of Y Combinator’s Winter 2023 batch.

Adjacent layer note: Honeydew and Atlan meet through the standard rather than through a connector. Both are named launch partners of Open Semantic Interchange, so a Honeydew model expressed in Ossie is portable into the same governed context an enterprise context layer serves to agents.

Pricing: Published. Lite is $20 per user per month plus a $500 monthly platform fee; Standard is $30 plus $2,000; Enterprise is custom and adds private deployment. A 14-day trial includes modeling guidance.

---

5. Atlan: the context layer that wraps semantic layers for AI

Atlan earns its place on this list as the layer that sits on top of whichever semantic engine you pick. Atlan reads and enriches semantic-layer definitions and adjacent metadata, binds them to lineage, glossary, ownership, and access controls, and serves that governed context to AI agents through the Atlan MCP Server. A semantic layer answers what a metric means. The context layer answers whether the agent is allowed to use it, who owns it, and where the number came from.

Who it’s for: Data and AI leaders building AI-agent workflows across one or more semantic layers, who need governance and MCP delivery layered on top of the stack they already have.

Key capabilities:

• Context Engineering Studio bootstraps, tests, and deploys governed context for AI systems like Cortex Analyst and Genie, complementing the semantic layers and warehouse-native models already in place
• Atlan MCP Server delivers governed context (definitions, lineage, policies, and audit-relevant metadata) to AI agents at inference time
• Enterprise Data Graph links metrics, glossary terms, lineage, and ownership across the stack so AI systems consume them as connected context, not isolated metadata
• Context Lakehouse and Context Repos provide versioned, portable, policy-aware context readable by MCP-connected agents and other AI systems
• Native dbt Semantic Layer ingestion and first-class cataloging of Looker semantic models, explores, views, and dashboards

Limitations:

• Not the right tool if you only need BI metric definitions on their own. In that case a pure semantic layer is usually the better first fit
• Maximum value usually comes from an existing semantic layer or governed metadata foundation. Context Engineering Studio can also bootstrap from dashboards, SQL, and metadata already in the stack

The clearest framing comes from Atlan’s own product language. A semantic layer answers what a metric means. Context Engineering Studio adds team context, exceptions, certification, and deployment-ready governance around that definition. That’s the extra context AI systems need to ground answers, cite definitions reliably, and support enterprise reviewability.

Workday reports a 5x improvement in AI response accuracy against pre-context-layer baselines after deploying Atlan’s MCP-delivered context. Snowflake Intelligence and Atlan delivered 3x query accuracy in a 522-query enterprise benchmark, which illustrates the gap between schema-only grounding and richer semantic-plus-context grounding.

Pricing: Custom enterprise pricing. Contact Atlan sales for pricing scoped to your stack.

---

6. Snowflake Semantic Views: warehouse-native metric definitions

The pitch is straightforward: if your stack already runs on Snowflake, why stand up a separate semantic service? Snowflake Semantic Views define metrics inside the warehouse, queryable by Cortex Analyst and Snowflake-native BI tools, with role-based access control inherited from the rest of the platform. The tradeoff is portability. Definitions don’t travel cleanly the day the organization decides to add Databricks.

Who it’s for: Snowflake-committed enterprises building Cortex Analyst or warehouse-native AI agents.

Key capabilities:

• SQL-based metric definitions native to Snowflake: no external service to maintain
• Direct consumption by Cortex Analyst for text-to-SQL use cases
• Apache Ossie participation (Snowflake is a launch partner)
• Native role-based access control inherited from Snowflake. No separate permissions layer needed

Limitations:

• Tied to Snowflake. Portability outside the warehouse is limited
• Newer than dbt SL or Looker. Feature set is still filling in
• Translation gaps between dbt semantic models and Snowflake Cortex semantic models are a known integration friction point for teams running both stacks

How Atlan extends Snowflake Semantic Views: Atlan’s Context Engineering Studio complements Snowflake-native semantic models by helping bootstrap, test, and deploy governed context for Cortex Analyst and related AI workflows.

Pricing: Included with Snowflake. Compute costs apply at query time.

---

7. Databricks Metric Views: lakehouse-native metric definitions

For Databricks shops, Metric Views is the equivalent move: define SQL-based metrics inside the Lakehouse, consume them through Genie, and inherit Unity Catalog governance across the rest of the platform. The AI-agent story is tight when Genie is the agent. It gets more complicated when it isn’t.

Who it’s for: Databricks-committed organizations building Genie or other Databricks-native AI features.

Key capabilities:

• SQL metric definitions native to Databricks, consistent with existing Lakehouse workflows
• Metric View YAML and DDL schemas for code-first metric definition
• Genie consumption for AI agents querying metrics in natural language
• Unity Catalog integration for governance alignment across Databricks assets

Limitations:

• Tied to Databricks. Portability outside the Lakehouse is limited
• Newer than dbt SL or Looker. Feature set is still filling in relative to established options
• Non-Genie agents need an additional integration layer to consume Metric Views

How Atlan extends Databricks Metric Views: Context Engineering Studio deploys to Genie and helps generate Metric Views from existing metadata. Atlan then binds those definitions to lineage, ownership, and approval context so agents consume more than the metric definition alone through the Atlan MCP Server.

Pricing: Included with Databricks. Compute costs apply at query time.

---

8. Looker and LookML: the BI-native original

Looker (now part of Google Cloud) defined the BI-native semantic layer category. LookML was the first code-first modeling language to make it into production at scale, and most modern semantic layers (including dbt SL and Cube) borrowed from its pattern. For Google Cloud and Gemini shops with mature LookML investments, it’s still the default. The tradeoff has shifted: Google now ships documented ways out of the Looker surface, and the question is whether your project meets their conditions.

Who it’s for: Google Cloud-committed enterprises with mature LookML investments, especially when Looker is the primary BI surface.

Key capabilities:

• LookML code-first semantic modeling: the originator of the pattern now adopted by dbt SL and Cube
• Tight Gemini integration for AI-augmented analytics within the Google Cloud ecosystem
• Native BigQuery optimization for Looker users on GCP
• The Open SQL Interface exposes LookML models over JDBC to third-party applications, which connect to a model as if it were a database. Google’s docs name Tableau, ThoughtSpot, Power BI, Looker Studio and Excel
• A Looker-managed MCP server, in Preview, that lets Claude Desktop, Gemini CLI, Cursor and Copilot query LookML models directly, inheriting the user’s Looker roles and content access

Limitations:

• LookML travels over JDBC only when the project runs on a BigQuery connection. Outside that setup, portability is limited
• The MCP server is Preview, so it carries Google’s pre-GA offering terms
• Google is not an Apache Ossie working-group member, so LookML definitions do not move through that standard

Google markets this layer as open, and the documented surfaces back that up. The residual gap is narrower than “LookML stays inside Looker”: the Open SQL Interface exports Looker’s definition of a number, and says nothing about whether a number produced elsewhere agrees with it.

How Atlan extends Looker and LookML: Atlan catalogs Looker semantic models, explores, views, and dashboards as first-class assets in the Enterprise Data Graph, with lineage, certification status, and access policies attached. AI agents querying through the Atlan MCP Server consume that LookML context together with the surrounding governance metadata needed for production use.

Pricing: Google Cloud pricing model. Looker Studio is free; Looker Studio Pro is the paid tier.

---

9. Power BI semantic models: the default for Microsoft estates

Formerly Power BI datasets, Power BI semantic models are what Power BI queries to populate a report. Microsoft describes them as a source of data ready for reporting and visualization. Measures are defined in DAX, and for Power BI workloads there is no route around the model: it is the layer every report reads. Plenty of teams run one without ever calling it a semantic layer.

Who it’s for: Microsoft-aligned organizations running Fabric or Azure Synapse, where Power BI is already the primary BI surface.

Key capabilities:

• DAX measures with three semantic model modes: Import, DirectQuery and Composite. Import stores data to disk and loads the whole model into memory to query it, with no partial load
• TMDL and Power BI Project (PBIP) files, so a semantic model lives in source control and changes flow through normal review
• XMLA endpoints for reaching the model from outside Power BI
• A Power BI Authoring MCP server for building models, offered both as a Microsoft-hosted endpoint and as a local server
• Fabric IQ as the consumption layer, answering natural-language questions grounded in Power BI semantic models and ontologies, and respecting the permissions, row-level security and object-level security already defined on them

Limitations:

• Portability outside the Microsoft estate is limited
• Microsoft is not an Apache Ossie working-group member
• The two MCP paths are not interchangeable. Microsoft’s own guidance is to keep the Authoring server out of consumption scenarios and route those through Fabric IQ

Fabric IQ is Microsoft’s supported path for data answers in Microsoft 365 Copilot, Copilot Studio, Foundry and custom agents. What it does not do is reconcile its answer with a number another tool produced from a different definition.

Pricing: Licensed through Power BI and Microsoft Fabric capacity rather than priced as a separate semantic layer.

---

10. ThoughtSpot Spotter Semantics: the semantic layer under the search interface

ThoughtSpot built its reputation on search-and-AI analytics, which only works if something underneath knows what the words mean. Spotter Semantics is that something: ThoughtSpot’s governed, AI-native semantic foundation, holding metric definitions, join logic, fiscal calendars and row-level security rules in a format AI agents read directly.

Who it’s for: ThoughtSpot shops grounding Spotter, and teams that want an external agent querying the same governed model the BI interface uses.

Key capabilities:

• Metric definitions, join logic, fiscal calendars and row-level security rules held in one governed model
• A model format built for direct agent consumption rather than exported to one
• A ThoughtSpot MCP server that wraps and orchestrates the Spotter APIs, letting AI agents ask natural-language questions, retrieve structured data or insights, and create Liveboards programmatically
• Named as a supported consumer of Looker’s Open SQL Interface and as one of the nine BI tools AtScale connects to, so it reads other vendors’ models as well as its own

Limitations:

• The semantic model is most useful inside ThoughtSpot’s own surfaces
• ThoughtSpot is not an Apache Ossie working-group member
• ThoughtSpot’s documentation surfaces the MCP server across several release versions, so confirm the status on the release you run before designing around it

Pricing: Published by ThoughtSpot on request. Contact ThoughtSpot.

---

11. GoodData.AI: analytics, data products and embedded agents

GoodData, which now brands as GoodData.AI and serves gooddata.ai after redirecting its old domain, sells analytics, data products and embedded agents. Its Logical Data Model treats multi-tenancy as the default, not an afterthought, so one metric definition can serve thousands of customer tenants with isolated per-tenant data access. Full embedding and whitelabeling sit on the Professional tier, which is narrower than “GoodData is an embedding company” and worth knowing before the evaluation.

Who it’s for: SaaS companies embedding analytics for end customers, plus distributed internal teams and partner-facing data products. Multi-tenant scenarios where one metric definition serves many tenants.

Key capabilities:

• Logical Data Model (LDM) for semantic modeling: versioned, reusable, multi-tenant by design. MAQL is the metric language
• White-label dashboard delivery with multi-tenant isolation, on the Professional tier
• Headless mode for API-only consumption in custom application builds
• An MCP server with 27+ tools covering workspace model retrieval, metadata browsing, analytics search and chat, LDM generation and alert management, documented under experimental features since January 2026

Limitations:

• The MCP server sits under experimental features, so treat its surface as subject to change
• GoodData is not an Apache Ossie working-group member
• Smaller ecosystem than dbt SL or Cube for third-party integrations

GoodData covers the embedded and data-product side. Atlan is the context layer for the internal stack. The two solve different problems.

Pricing: Two published tiers. Professional is a platform fee plus per-workspace pricing; Enterprise is custom. Neither carries a public dollar figure and both route through Contact us.

---

12. Sigma data models: the semantic layer that stays on the warehouse

Sigma’s answer to the modeling question is to not move the model. Sigma data models provide a semantic layer that centralizes business logic and metrics, managed as governed assets directly on the warehouse rather than in a separate service. For teams whose objection to a semantic layer is “another system to run,” that framing does real work.

Who it’s for: Sigma shops that want governed business logic centralized without standing up a semantic service beside the warehouse.

Key capabilities:

• Data models centralizing business logic and metrics as governed assets managed on the warehouse
• A dbt Semantic Layer integration, so an existing MetricFlow investment reaches Sigma without redefinition
• A Snowflake semantic views integration, in Beta
• Spreadsheet-style authoring over warehouse data, which keeps model maintenance closer to the analysts who own the logic

Limitations:

• The semantic layer is most useful inside Sigma’s own surface
• Sigma is not an Apache Ossie working-group member
• Sigma’s documentation covers data modeling and its dbt and Snowflake integrations. It does not document an MCP server, so plan agent access through the integrations rather than around one

Pricing: Sigma prices by platform and user. Contact Sigma.

---

13. Tableau Semantics: the BI-native layer most buyers still miss

Tableau spent a decade as the tool other semantic layers fed, which is why so many comparisons still file it under consumers. That stopped being accurate. Tableau Semantics is Tableau’s own AI-infused semantic layer, and its semantic models map raw data to business-friendly terms and logic. It ships with Tableau Next as part of the Tableau+ SKU and with Data 360, and a Tableau Semantics connector arrived in Tableau Desktop 2025.2 for Desktop and Tableau Cloud.

Who it’s for: Tableau Next, Data 360 and Tableau+ estates that want the metric definition governed where the dashboards already live.

Key capabilities:

• Semantic models mapping raw data to business-friendly terms and logic
• Ships with Tableau Next under the Tableau+ SKU and with Data 360
• A Tableau Semantics connector in Tableau Desktop since 2025.2, reaching Desktop and Tableau Cloud
• Authoring and Semantic Query REST APIs, including a Semantic Metric Query API, so a client can create models and query metrics programmatically over standard Salesforce REST
• Salesforce sits in the Apache Ossie working group, so Tableau is inside the portability standard that Looker’s owner is outside of

Limitations:

• Tableau’s documentation covers Semantics through Tableau Next, Data 360 and the Desktop connector. It does not document an MCP surface, so agent access is a question to put to Tableau rather than an assumption to build on
• Programmatic access runs through Salesforce REST authorization, so a caller needs a Salesforce org. The model is queryable outside Tableau, not outside Salesforce
• Newest entry in this category, so production references are thinner than Looker’s or Power BI’s

Tableau Semantics ranks thirteenth here for one reason: the criterion is documented AI-agent readiness, and Tableau documents REST query access but no MCP surface, which several entries above it do. That is a statement about the docs in September 2026, not a prediction. A documented MCP surface would move it.

Pricing: Bundled with Tableau Next under Tableau+ and with Data 360 rather than sold as a separate semantic layer.

---

14. MicroStrategy ONE: enterprise BI semantic heritage

MicroStrategy’s semantic model predates the term “semantic layer” by a decade. Banks, insurers, and Fortune 500 retailers built years of business logic on top of it. MicroStrategy ONE is the modern wrapper around that investment, with HyperIntelligence overlays for embedded analytics and an Auto AI agent for natural-language query. Greenfield teams should keep looking. Teams already running MicroStrategy can stay there while picking up AI augmentation on top.

Who it’s for: Fortune 500 organizations with mature MicroStrategy investments in financial services, insurance, and large retail. Not for greenfield builds.

Key capabilities:

• Schema-based semantic modeling with decades of production maturity
• HyperIntelligence for embedding analytics context into enterprise applications
• AI/BI agent (Auto) for natural language query on top of the semantic model
• Native security inheritance and broad connector coverage for legacy enterprise systems

Limitations:

• Heavyweight platform. Longest implementation cycle of any tool on this list
• AI-agent readiness is improving but lags Snowflake, Databricks, and dbt SL native options
• Not an Apache Ossie working-group member, which is a portability risk as the standard matures

How Atlan extends MicroStrategy ONE: Atlan as context layer exposes MicroStrategy semantic objects to MCP-connected agents with an audit trail.

Pricing: Enterprise licensing. Contact MicroStrategy.

---

Which tools market themselves as semantic layers but aren’t?

Some tools market themselves as semantic layers when they actually live in adjacent categories: OLAP query accelerators and agent-orchestration layers. Each has merit in its real category. The buying decision changes the moment you name the category accurately, and a category-adjacent tool used in place of a true semantic layer creates downstream integration debt.

A BI tool with built-in semantic modeling is not in that group. Seven of the fourteen entries above are exactly that, and they belong on the list. The question there is reach, not legitimacy: how far outside its own surface a BI-native model travels, and through which documented interface.

Holistics is worth naming for a different reason. Its semantic modeling, Analytics Modeling Language and AQL, is real and strong inside the Holistics BI surface. Holistics documents that modeling for its own product; how far those definitions reach agents or third-party BI tools is the thing to establish with the vendor before you treat it as a universal layer. Read alongside the ontology vs semantic layer comparison.

A reliable test: ask which semantic layer the tool consumes or replaces. If the answer is “we are the semantic layer” but the core function is OLAP acceleration or agent orchestration, the tool is category-adjacent. Naming the category accurately costs nothing and saves months of buyer regret.

---

Is dbt a semantic layer or a metrics framework?

dbt itself is a transformation framework. The dbt Semantic Layer (powered by MetricFlow) is a separate layer built on dbt models that defines, computes, and serves metrics. Many teams say “we use dbt” when they mean transformations only.

Three distinct layers in the dbt stack:

• dbt OSS is the open-source distribution, Apache 2.0, renamed from dbt Core v2 when dbt v2 went GA on 2026-09-16. dbt v1, the Python generation, stays maintained; 1.13 is its last feature release
• the dbt platform, formerly dbt Cloud, is the managed product: IDE, scheduling, CI/CD, and collaboration
• dbt Semantic Layer is the metric definition layer: MetricFlow YAML definitions, served via API to BI tools and AI agents, on a Starter or Enterprise-tier account

If your dbt project does not have MetricFlow definitions, you have dbt but not the Semantic Layer. There is a second gate: the Semantic Layer also needs a dbt platform Starter or Enterprise-tier account, so a dbt OSS user with MetricFlow definitions still does not have the hosted Semantic Layer. Adopting it extends the workflow from transformation to metric definition. See the Atlan dbt Semantic Layer integration.

Core, Cloud, and Semantic Layer: what each layer actually does. Image by Atlan.

---

Do you need a semantic layer if you already have a data catalog?

A data catalog and a semantic layer solve different problems. The catalog indexes what data exists and who owns it. The semantic layer defines what metrics mean and how to compute them. Enterprises building AI agents need both, plus a context layer to govern how the agent uses metric definitions.

A data catalog answers “what data do we have?” A semantic layer answers “what does ‘monthly active users’ mean?” A context layer answers “how does an AI agent use that definition safely?” Most enterprises run all three. What is a context layer walks through the stack with production examples.

---

Customer evidence: how DigiKey and CME Group govern semantic layers for AI

Three enterprise customers anchor the pattern. DigiKey activated marketplace metadata into AI governance and MCP-delivered context. CME Group put 18 million assets and 1,300 glossary terms into production in year one of its context-layer build with Atlan. Gartner named Atlan a Leader in the 2026 Magic Quadrant for Data & Analytics Governance, citing AI-native governance through context-based partnerships and agentic stewardship.

DigiKey

Atlan activated marketplace metadata for DigiKey, one of the largest electronic-component distributors in the world, by surfacing product, supplier, and pricing context into AI governance and serving it to AI agents via an MCP server.

CME Group

Scale proof: 18 million assets cataloged with 1,300 glossary terms in year one of the context-layer build. The glossary terms are the semantic investment. The catalog is the governance layer.

Context Agents Accelerator

In a 2-week program with 50+ enterprise customers in April 2026, Atlan’s Context Agents generated 690,000+ description updates with 87% rated on par or better than human. Work that took 9-12 months in governance-first programs now ships in 30 days.

---

How should you evaluate a semantic layer for the AI era?

Use the Context-Era Semantic Layer Test, four axes: category honesty, AI-agent readiness (MCP, governance signals, citation support), Apache Ossie standing, and context-layer integration.

Four moves separate teams that ship AI agents from teams rebuilding metric definitions every quarter:

1. Pick a pure semantic layer first. Whether that’s dbt Semantic Layer, Cube, AtScale, Snowflake Semantic Views, or Databricks Metric Views depends on your stack. Do not let a context layer or catalog tell you it replaces this step.

2. Layer a context layer on top. The context layer binds metric definitions to lineage, ownership, business glossary, and access policies, then exposes that governed context via MCP. Without it, AI-agent answers may still be correct on the metric itself but remain harder to govern, audit, and trust at production scale. Semantic layers without governance is a documented failure mode.

3. Check where the vendor stands on Apache Ossie, and decide how much it should weigh. A semantic layer that locks definitions to one vendor’s syntax becomes a migration problem as the standard matures. Treating membership as a hard filter is a bigger decision than it looks: it rules out Looker, Power BI, ThoughtSpot, Sigma, GoodData and MicroStrategy, which is most of the BI-native category. Weigh it against how likely you are to move the definitions at all.

4. Validate AI-agent readiness with a real agent query. Ask: “Can a Cortex Analyst or Genie agent answer Q1 ARR correctly AND cite which definition it used?” If the answer is no, the stack is not AI-ready.

---

Pair your semantic layer with a context layer

The AI-agent-readiness question is what sits on top of your semantic layer. A semantic layer defines metrics. A context layer governs how those definitions get used, cited, and trusted by AI agents. Atlan’s Context Engineering Studio, MCP Server, and context-layer architecture are designed to wrap the semantic layers already in your stack so teams can govern the definitions they already have and expose them through MCP.

---

Frequently asked questions

Which semantic layer tool is fastest to deploy?

Snowflake Semantic Views and Databricks Metric Views deploy fastest when your stack is already on the warehouse, because definitions live where the compute runs and there’s no separate service to stand up. For dbt-committed teams, dbt Semantic Layer ships metrics through the same YAML and CI/CD path as transformations. Heavyweight enterprise platforms like AtScale and MicroStrategy ONE run quarters, not weeks.

What is the difference between a semantic layer and a metadata layer?

A semantic layer defines what metrics mean and how to compute them. A metadata layer indexes what data exists, where it lives, and who owns it. Modern enterprises use both: the metadata layer (often a data catalog) underneath, the semantic layer on top for analytical consumption.

Can I switch from Snowflake Semantic Views to Databricks Metric Views?

Warehouse-native semantic definitions do not move cleanly between warehouses. Snowflake Semantic Views and Databricks Metric Views each use their own SQL dialect, governance model, and consumption surface (Cortex Analyst versus Genie). Teams running both warehouses typically maintain parallel definitions or use a context layer that wraps both and exposes a unified governed view to AI agents via MCP.

Do semantic layer tools work without dbt?

Yes. Cube, AtScale, Honeydew, Snowflake Semantic Views, Databricks Metric Views, Looker/LookML, Power BI semantic models, ThoughtSpot Spotter Semantics, GoodData, Sigma data models, Tableau Semantics, and MicroStrategy ONE all define metrics independently of dbt. dbt Semantic Layer is the option that ties metric definitions to dbt models. The rest define metrics in their own DSL, SQL, or UI. Pick by where your team owns business logic, not by dbt commitment.

Is Snowflake a semantic layer?

Snowflake is a cloud data warehouse, not a semantic layer. Snowflake Semantic Views is a newer Snowflake feature that lets teams define metrics inside the warehouse, queryable by Cortex Analyst and BI tools. It functions as a warehouse-native semantic layer for Snowflake-committed shops.

How long does a semantic layer implementation take in 2026?

Implementation time depends on scope. Code-first semantic layers (dbt Semantic Layer, Cube) deliver first metrics within weeks once the underlying models exist. Warehouse-native options (Snowflake Semantic Views, Databricks Metric Views) ship faster when the team already runs on that warehouse. Enterprise platforms (AtScale, MicroStrategy ONE) run quarters. Pairing a context layer compresses governance work from 9-12 months to 30 days for the 50+ customers in Atlan’s 2026 Context Agents Accelerator.

What does Atlan’s MCP Server cost?

There is no additional charge for the Atlan MCP Server today. Atlan pricing is custom enterprise based on your stack, asset footprint, and usage profile. Contact Atlan sales for a scoped quote.

What is Apache Ossie, formerly Open Semantic Interchange?

Apache Ossie is an emerging standard for defining metrics and semantic objects in a vendor-neutral format. It launched in September 2025 as Open Semantic Interchange, with backing from Snowflake, Salesforce, dbt Labs, Atlan, Cube, Honeydew and others, and it lets semantic-layer definitions move across BI tools, warehouses, and AI agents without rewriting. It has since been accepted into the Apache Incubator as Apache Ossie. dbt Labs published the first version of the specification with its partners on 2026-01-29, and dbt’s docs accept only version 0.1.0 or 0.1.1. There is no 1.0 spec.

---

Sources

1. Snowflake Intelligence + Atlan: 3x query accuracy. Snowflake Intelligence + Atlan partner talk-to-data (522-query enterprise benchmark; 95%+ reliability when grounding text-to-SQL in glossaries + semantic layers + quality metadata vs schema-only)
2. dbt Semantic Layer launch + MetricFlow. dbt Semantic Layer quickstart documentation
3. Apache Ossie, formerly Open Semantic Interchange. github.com/apache/ossie and Ossie semantic models, dbt Developer Hub
4. Snowflake Cortex Analyst documentation. Snowflake Cortex Analyst overview
5. Cube data model and API reference. Cube documentation
6. Databricks Metric Views + Genie integration. Databricks Metric Views product documentation (Metric View YAML/DDL schema and Genie consumption)
7. AtScale semantic layer platform. AtScale semantic layer documentation
8. Honeydew modeling, query surfaces, MCP server, and pricing. Honeydew documentation and Honeydew pricing
9. Open Semantic Interchange launch partners (Honeydew and Atlan both named). Snowflake, Salesforce, dbt Labs and more launch OSI
10. Snowflake Ventures investment in Honeydew, with Pizza Hut results. Snowflake Ventures invests in Honeydew
11. Looker semantic layer beyond Looker. Open SQL Interface and the Looker-managed MCP server (Preview)
12. Power BI semantic models, modes, and MCP surfaces. Semantic models in the Power BI service, semantic model modes, and Power BI MCP servers overview (Authoring server and Fabric IQ)
13. ThoughtSpot Spotter Semantics and MCP server. ThoughtSpot semantic layer and Spotter connectors
14. Tableau Semantics. Tableau Semantics in Tableau Desktop, connector shipped in Tableau Desktop 2025.2
15. Sigma data models and semantic-layer integrations. Get started with data modeling and dbt Semantic Layer integration
16. GoodData.AI tiers and positioning. GoodData pricing
17. Apache Ossie working-group membership. open-semantic-interchange.org, the roster behind every Ossie column value on this page