12 Best Semantic Layer Tools for AI and BI in 2027

Every BI vendor in 2027 demos the same AI chat. "Show revenue by region." "Top 10 products by sales." A look-up question on a single fact table will impress any modern LLM, on any platform. It says almost nothing about whether the underlying system can answer the questions your business asks day to day.

The real differentiator is the semantic layer underneath, and not all semantic layers are equal. The differences show up the moment you move past demos and into the daily reality of nested aggregations, period-over-period comparisons, cross-grain ratios, and multi-step calculations, the questions that actually fill the analyst queue.

This guide compares the 12 best semantic layer tools in 2027 across four architectures: BI-native, open-source, standalone, and warehouse-native. We'll explain what separates a primitive configuration layer from a programmable one, introduce the concepts of the semantic ceiling and semantic leakage, and help you decide which architecture fits your team.

If you're only evaluating BI tools with a built-in semantic layer, see our comparison of BI tools with a semantic layer.

What Is a Semantic Layer?

A semantic layer is a centralized definition of business metrics, dimensions, and logic that sits between the data warehouse and every downstream consumer: dashboards, AI agents, APIs, notebooks, and embedded analytics.

Instead of writing "monthly revenue" logic in five different SQL queries, you define it once in the semantic layer and use it consistently everywhere. A data catalog is a dictionary: it tells you what words exist, customer, subscription, churn. The semantic layer is the grammar. It encodes how definitions combine, which metrics are canonical, and how "revenue by quarter" is supposed to work across every dashboard, report, and now, every AI prompt.

The semantic layer sits between the warehouse and every consumer: dashboards, AI, APIs. Source: vutr.substack.com

Why semantic layers matter more in 2027

Semantic layers are having their second renaissance because AI made the cost of ambiguity impossible to ignore.

This is not a new conviction for us. We have been advocating for this layer for six years, starting with our Analytics Setup Guidebook in 2020.

The argument in the guidebook was that the mapping between business logic and data logic has to move out of an analyst's head and into an explicit modeling layer. Business users should be able to work with business concepts, while the layer handles the translation into correct data logic. This is the foundation of self-service analytics.

The semantic layer sits between the warehouse and every consumer: dashboards, AI, APIs. Source: vutr.substack.com

We extended the same argument in a 2023 dbt Singapore meetup talk on the ideal semantic layer. The talk started from metrics-centric thinking: metrics should be first-class objects that compose, parameterize, and travel across dimensions at query time. If an LLM has to generate raw SQL over raw tables, it has to guess. If it can express intent against a semantic layer, the hard parts, joins, grains, metric definitions, and governance, stay deterministic.

A mature semantic layer turns AI from a guesser into a deterministic partner. Instead of asking an LLM to reason over raw tables, you give it the grammar, metrics, dimensions, relationships, that are already agreed upon. The model is grounded in it.

Four Types of Semantic Layer Tools

The semantic layer market divides into four architectures. Each trades off integration breadth, user experience, and expressiveness differently.

• BI-native (bundled): the semantic layer and the dashboards, exploration, and AI that consume it live in one platform. Tools: Holistics, Looker, Power BI, ThoughtSpot.
• Open-source: the semantic layer's code is public and you can self-host it, so definitions stay portable and nothing is locked behind a vendor. Tools: anfra, MetricFlow, Malloy, plus Cube's open-source core (Cube Core).
• Standalone (headless): a metrics layer between the warehouse and many downstream tools, served over APIs. You still need a BI tool, notebook, or app to show the numbers. Tools: dbt Semantic Layer, Cube, AtScale.
• Warehouse-native: the data warehouse itself stores metric definitions that any connected tool can query. Tools: Snowflake Semantic Views, Databricks Unity Catalog Metric Views.

Below, we compare all 12 side by side and profile each one, then show how to test any of them on your own data.

Best Semantic Layer Tools for AI and BI: Features and Pricing

Here is the landscape at a glance, with a full profile of each tool below. "Ceiling" is how far the layer answers complex questions (nested aggregation, period-over-period, cross-grain ratios, cohorts) natively, before logic leaks into workarounds.

We build Holistics, so treat its placement as a disclosed view, not a neutral ranking – and judge every tool here on the same test: can it answer your hardest question natively, keep one definition of every metric, and let any tool or agent query it?

1. Holistics

Holistics turns warehouse tables into data models, then groups models, relationships, and metrics into datasets that power charts and dashboards. Source: Holistics documentation.

Holistics takes a programmable approach with AML (Analytics Modeling Language) for defining models and AQL (Analytics Query Language) for composable, multi-step metric calculations. AQL operates at a higher abstraction than SQL, handling nested aggregations, period-over-period, cross-grain ratios, and running totals natively. Because it's typed, invalid field references and semantic issues are caught as you type, not at runtime. The core shift is from table-centric modeling to metrics-centric thinking: metrics are first-class objects that can reference other metrics, be parameterized, and compose into arbitrary depth.

Key features:

• AQL composable metrics: nested aggregation, period-over-period, cross-grain ratios (of_all()), running totals, and cohorts as native operations
• AML programmable modeling: constants, functions, extend, and modules keep models DRY, with a type-safe IDE that catches errors as you type
• Native 2-way Git: branches, pull requests, and CI/CD across dev, staging, and production for every model, metric, and dashboard
• AI on the governed layer: AI generates AQL rather than raw SQL, and an MCP Server lets external agents query the same metrics
• Open semantic layer: query any dataset's metrics over an API and get JSON back, for notebooks, scripts, and internal services
• Embedded analytics: one model and its row-level security power internal dashboards and customer-facing embeds

Pricing: Starts at $800/month. A free trial is available.

2. AtScale

AtScale's Design Center canvas shows a semantic model's dimensions and relationships, with a text editor tab for the underlying SML. Source: AtScale documentation.

AtScale takes an enterprise-oriented approach, providing a virtual semantic layer that connects to existing BI tools (Tableau, Power BI, Excel) without requiring migration. It translates OLAP-style queries into optimized warehouse SQL. Best suited for organizations with heavy existing BI investments that want consistent definitions without replacing their tools.

Key features:

• Virtual OLAP cubes: dimensional models on top of the cloud warehouse, without moving data
• Multi-tool connectivity: live connections for Excel, Power BI, and Tableau
• Autonomous aggregates: automatically created aggregates to speed up queries
• SML: an open-source, code-based Semantic Modeling Language

Pricing: Custom enterprise pricing. A free Developer Community Edition is available.

3. Cube

Cube sits between data sources and applications, handling modeling, access control, caching, and APIs. Source: Cube on GitHub.

Cube provides a headless semantic layer with its own query engine. Its "Views" feature lets teams compose virtual tables from multiple data sources, exposed through REST, GraphQL, and SQL APIs. Cube's strength is integration breadth: it serves BI tools, notebooks, applications, and AI agents from one definition layer. The modeling language (YAML or JavaScript) supports basic metric composition but, like dbt, complex multi-step calculations often require pre-computation.

Key features:

• Data model in YAML or JavaScript: cubes, views, measures, and dimensions
• REST, GraphQL, and SQL APIs: connect BI tools, apps, and AI agents
• Pre-aggregations: a caching layer for fast, cost-efficient queries
• Access control: row-level security defined in the model

GitHub: cube-js/cube

Pricing: Cube Core is open source and free. Cube Cloud has a free tier, with paid plans billed on usage and custom Enterprise pricing.

4. MetricFlow

MetricFlow turns normalized tables into semantic models, then joins them on demand to answer metric queries. Source: dbt documentation.

MetricFlow is the open-source engine behind the dbt Semantic Layer. You describe semantic models (entities, dimensions, and measures) and metrics in YAML, and MetricFlow works out the joins and generates the SQL for each metric query. You can run it on its own from the command line or as a Python library, without the hosted dbt Semantic Layer, though you then build your own way to serve metrics to other tools.

Key features:

• Semantic models and entities: MetricFlow uses entities to find join paths between models, so a query can mix measures and dimensions from different tables
• Metric types: simple, ratio, cumulative, derived, and conversion metrics
• Dialect-aware SQL: compiles to SQL for Snowflake, BigQuery, Databricks, Redshift, PostgreSQL, DuckDB, Trino, and more
• CLI and Python library: query metrics with mf query or call the engine from your own code

GitHub: dbt-labs/metricflow

Pricing: Free and open source (Apache 2.0). The hosted dbt Semantic Layer, which adds APIs and BI integrations, needs a paid dbt plan.

5. Looker

The Looker IDE in Development Mode, with an orders view defined in LookML. Source: Looker documentation.

Looker pioneered code-based semantic modeling with LookML. SQL-based metric definitions give explicit control over generated SQL, with "symmetric aggregates" handling many-to-many joins. The language is YAML-based, powerful for standard use cases, but lacks the functions, variables, and code reuse of a full programming language. Complex metrics like cumulative sums often require building manual derived tables.

Key features:

• LookML: views, dimensions, measures, and Explores defined centrally in code
• Symmetric aggregates: correct totals across fan-out joins
• Native Git integration: branching and code review for LookML projects
• Period-over-period measures: native period_over_period measure type (GA since August 2025)
• Gemini in Looker: conversational analytics grounded in LookML definitions

Pricing: Custom, through Google Cloud sales. According to Vendr, the median buyer pays about $89K per year.

6. Power BI

Power BI Desktop's Model view: a Sales fact table joined to dimension tables, with the semantic model's measures, relationships, and roles in Model explorer. Source: Microsoft Learn.

Power BI uses DAX (Data Analysis Expressions) inside a tabular semantic model. DAX is powerful for certain patterns (time intelligence, calculated columns) but operates within a proprietary in-memory engine. The model is GUI-configured in Power BI Desktop, and complex logic often requires understanding both DAX and the VertiPaq engine's behavior.

Key features:

• DAX measures: iterator functions (SUMX, AVERAGEX) and CALCULATE cover nested and cross-grain patterns
• Time intelligence: mature built-ins like SAMEPERIODLASTYEAR and DATEADD
• TMDL: a text-based format for semantic models, with Fabric Git integration
• Copilot and Fabric data agents: natural language questions over the semantic model

Pricing: Power BI Pro is $14/user/month and Premium Per User is $24/user/month. Fabric capacity, needed for Copilot and enterprise features, starts at roughly $262/month for the F2 tier.

7. ThoughtSpot

The ThoughtSpot Model editor, where tables are joined on a canvas, with tabs for columns, formulas, filters, and parameters. Source: ThoughtSpot documentation.

ThoughtSpot centers on search-driven analytics with TML (ThoughtSpot Modeling Language) for semantic definitions. Its strength is the search interface for business users; its semantic layer handles standard OLAP patterns well but is more constrained for multi-step metric composition. (For replacements, see our ThoughtSpot alternatives guide.)

Key features:

• Models: joins, columns, and formulas defined in one place, exportable as TML
• Spotter: an AI analyst for natural language questions
• Formula functions: reaggregation, cumulative, moving, and semi-additive functions
• MCP Server: available as an add-on for external agents

Pricing: The Essentials plan starts at $25/user/month. Pro and Enterprise are custom-priced.

8. anfra

Your app asks the anfra SDK for metrics by name, and the anfra server turns each interaction into a query on your semantic layer that runs on the warehouse. Source: anfra.ai.

anfra can be categorized as an open-source semantic layer, but its capabilities extend far beyond a regular semantic layer. If anything, it's more of a semantic framework for AI. Coding agents build fully custom data apps on it, in HTML, JavaScript, and any chart library, and every number in those apps comes from governed metrics rather than SQL the agent improvised.

What sets it apart is who it's built for. In anfra, a definition can come from many authors, people and agents alike, and an agent busy building an analysis may not think of security. So anfra guards every definition for its author: each one runs in a sandbox and reaches data only through the SDK, which offers everything a Data App needs. The safe way is the only way, and also the easy one, and every feature below follows from that.

Key features:

• Semantics for custom front ends: anfra sits between a custom HTML/JavaScript app and the semantic layer underneath, so even a hand-built app requests metrics by name instead of running raw SQL. Tools that skip the semantic layer and have the agent write SQL directly can't give you this.
• Every number can be traced: an Inspect panel lists every query that ran on the page and traces each one to its metrics and models, with lineage, the semantic query, and the generated SQL. Try it on the ecommerce overview demo, a dashboard built entirely by coding agents: click Inspect at the bottom right.
• Trust without giving up flexibility: there are no fixed chart types or layouts. The apps on the demo site are each tailored to a different use case, and all of them are governed because they run on the same SDK.
• Built for coding agents: an MCP endpoint and one-step setup for Claude Code and Cursor. When models don't exist yet, the agent drafts them and your data team reviews them in a pull request.
• Runs on your infrastructure: a single binary that connects to Snowflake, BigQuery, Databricks, Redshift, PostgreSQL, ClickHouse, DuckDB, and more.

GitHub: holistics/anfra

Pricing: Free and open source (Apache 2.0). anfra Cloud, which adds login, permissions, and row-level security, is on a waitlist and hasn't published pricing yet.

9. Malloy

You define a semantic model in a .malloy file, the Malloy compiler turns queries into SQL for your database, and the SQL runs on your warehouse. Source: Malloy on GitHub.

Malloy is an open-source language that is both a semantic modeling language and a query language. You define sources with joins, dimensions, and measures, then write queries against them, and Malloy compiles each query to SQL that runs on your existing database. It's more expressive than most YAML-based layers: nested queries and multi-stage pipelines are part of the language, so results like "top products within each region" come from one query.

Key features:

• Semantic sources: joins, dimensions, and measures defined once and reused by every query
• Nested queries and pipelines: nested result sets and multi-stage queries without hand-written CTEs
• Symmetric aggregates: correct totals across joins that would otherwise fan out
• Many SQL engines: BigQuery, Snowflake, DuckDB, MotherDuck, PostgreSQL, MySQL, Trino, Presto, and Databricks
• Several ways to use it: a VS Code extension with notebooks, npm packages, a CLI, Python, and Publisher for serving models

GitHub: malloydata/malloy

Pricing: Free and open source (MIT).

10. dbt Semantic Layer

Metrics are defined in dbt next to the models, and downstream tools such as BI tools, notebooks, and data apps send Semantic Layer queries to get metric data back. Source: dbt documentation.

dbt Semantic Layer (MetricFlow) extends dbt's transformation layer into a full metric definition system. You define metrics in YAML alongside your dbt models, and MetricFlow compiles them to SQL at query time. Because dbt already owns the transformation layer in many stacks, the semantic layer inherits that context. The trade-off: metric definitions live in YAML configuration files, which can become verbose for complex composition. MetricFlow supports derived metrics (metrics referencing other metrics) but the language lacks the programming constructs (functions, variables, modules) of a full-blown modeling language.

Key features:

• MetricFlow: simple, ratio, cumulative, derived, and conversion metric types
• Defined next to dbt models: metrics live in the same Git repo and project as transformations
• APIs and integrations: JDBC and GraphQL APIs, plus connectors for BI tools and spreadsheets

Pricing: Available on paid dbt plans. The Starter plan is $100 per developer seat/month; Enterprise is custom.

11. Snowflake Semantic Views

A Snowflake semantic view sits on top of transformed data and gives AI tools, BI tools, and SQL users one shared business layer. Source: Snowflake documentation.

Snowflake stores semantic definitions as native database objects. Semantic views describe tables, relationships, facts, dimensions, and metrics inside Snowflake, and Cortex Analyst uses them to answer natural language questions. The promise: define metrics once at the warehouse level, consume them in any connected tool. The reality in 2027: expressiveness is still limited compared to dedicated semantic layer tools.

Key features:

• Semantic views: metrics, dimensions, and relationships as Snowflake schema objects
• Cortex Analyst: natural language to SQL grounded in semantic views
• Snowflake governance: access controlled through existing roles and privileges

Pricing: No separate license. You pay Snowflake compute credits for queries, and Cortex Analyst is billed per message.

12. Databricks Unity Catalog Metric Views

A metric view is defined in YAML or SQL over Unity Catalog tables, and the same dimensions and measures serve both code and no-code tools. Source: Databricks documentation.

Databricks adds metric views to Unity Catalog. Metric views are defined in YAML, registered alongside tables, and queried through SQL, with AI/BI dashboards and Genie consuming them. Like Snowflake's approach, it optimizes for breadth over depth: any connected tool can consume the definitions, but the modeling language is simpler than what dedicated tools offer.

Key features:

• Metric views: YAML-defined measures and dimensions registered in Unity Catalog
• Unity Catalog governance: permissions, lineage, and auditing in one place
• AI/BI integration: dashboards and Genie use the same definitions

Pricing: No separate license. You pay for the Databricks compute (DBUs) that runs the queries.

How to Evaluate Semantic Layer Tools

Every tool in this guide has something it calls a "semantic layer." But the range of questions each layer can answer natively varies widely, and that difference compounds as AI becomes the primary analytics interface. So don't test the chat box. Test the layer underneath, starting with two concepts: the semantic ceiling and semantic leakage.

The semantic ceiling

Most conventional semantic layers handle the OLAP basics: lookup, slice-and-dice, filter/group, top-N. These resonate with end users familiar with pivot tables, and this is what most vendors show in demos.

But there is a non-trivial class of questions that conventional semantic layers cannot answer natively:

When a semantic layer hits this ceiling, three things happen:

1. Data teams build derived tables, pre-computing metrics in dbt or LookML derived tables and bypassing the semantic layer entirely
2. End users run calculations at the dashboard level, using table calculations, spreadsheet exports, and dashboard formulas instead of the governed layer
3. Requests go back to analysts, the question becomes a ticket in the analyst queue, undoing the promise of self-service

The ceiling of your semantic layer is the ceiling of your AI analytics. If the layer cannot express a question natively, AI either falls back to raw SQL (reintroducing hallucination risks) or simply returns nothing.

Semantic leakage

Semantic leakage is what happens when business logic escapes the governed semantic layer into ungoverned locations:

• Upstream into dbt models, derived tables, and near-duplicate transformations
• Downstream into dashboard formulas, table calculations, spreadsheets, and custom report code
• Side-channel into analyst memory and ad-hoc Slack clarifications

Over time, metric definitions fork across these locations. Trust erodes. The semantic layer loses its authority as the single source of truth.

Semantic leakage compounds the problem. As end users ask increasingly sophisticated questions through AI interfaces, they will inevitably hit questions that the semantic layer can't answer natively. When that happens, AI falls back to text-to-SQL from scratch, reintroducing the hallucination and inconsistency the semantic layer was supposed to eliminate.

For a detailed visual walkthrough of the ceiling and leakage concepts, see Not all semantic layers are equal.

The evaluation checklist

Here are the questions that separate a PoC that will age well from one that will cost your team for years:

group() | aggregate() | aggregate()

previous() · relative_period()
period_to_date()

with_relationships()
filter(cohort_dim)

relationship()
with_relationships()

metric args · dataset fields

pipe | · metric-of-metric

Test the layer, not the demo:

• Can it express "average order value by region, then rank regions by that average"? (nested aggregation)
• Can it calculate "month-over-month revenue growth by segment" without a pre-built derived table? (period-over-period)
• Can it answer "each region's share of total revenue" in a single metric? (cross-grain ratio)
• Can it define "N-day activation rate" once and parameterize N? (composable, parameterized metrics)

Find the leakage:

• When the semantic layer can't answer a question natively, where does the logic go?
• How many derived tables / dbt models exist solely to work around semantic layer limitations?
• How many table calculations or workbook-level formulas duplicate metric logic?
• Can a new analyst find all metric definitions in one place, or must they check dashboards, transformations, and Slack threads?
• If AI generates a wrong answer, can a business user trace it to a governed definition, or is it raw SQL?

To see how the tools in this guide compare across these dimensions, go back to the comparison table.

Choosing the right architecture

Once you know what to test, choosing an architecture comes down to three questions:

• Where do you want meaning to live? Choose BI-native if your team works mainly in dashboards and self-service exploration, open-source if you want to self-host or let coding agents build on governed definitions, standalone if many tools must share one definition of "revenue", and warehouse-native if you want consistency without replacing existing tools.
• How complex are your metrics? If your analysts build derived tables for nested aggregations, period-over-period, or cross-grain ratios, you need a layer that handles these natively. Test it with a question like "Of customers who signed up in January, what was 30-day conversion vs. April's cohort, and how does ARPU compare for the two groups?"
• How important is AI readiness? The higher a layer's ceiling, the more questions AI can answer with governed metrics before it falls back to raw text-to-SQL (see how BI tools with a programmable semantic layer differ).

Is Holistics a semantic layer?

You might have already heard this argument somewhere: a "true" semantic layer is a standalone, headless component that serves metrics to external tools and agents (think dbt Semantic Layer or Cube), and anything else, Holistics included, is just "a BI tool with built-in modeling", category-adjacent, and using it in place of a real semantic layer creates integration debt.

We build Holistics, so treat this as a disclosed answer rather than a neutral one. We don't think it's a fair argument. The critique defines "semantic layer" as "headless metrics API", then rules that everything not built that way is not the real thing. That is circular. A semantic layer should be defined by what it does: a centralized, governed definition of metrics and dimensions that guarantees the same question returns the same number everywhere. Headless delivery is one architecture for that job, not the definition of the job. By the same logic Looker's LookML would not qualify, and no one seriously argues that.

And the definition also goes both ways. A headless layer cannot answer a business question or govern an experience on its own. We can't talk about semantic layer, without talking about the consumption endpoint of the semantic layer. It is metric plumbing that still needs a downstream BI tool, notebook, or app to produce anything a person sees. Bolt one onto a separate BI tool and you now run two governance surfaces and inherit the gap between what the layer can express and what the downstream tool can actually render. That seam is exactly where semantic leakage lives.

The more important thing is that Holistics semantic layer is open.

Your Holistics semantic layer is queryable over an API. You can request a dataset's dimensions and metrics from outside Holistics and get results back as JSON, so the same governed metrics behind your dashboards can power Jupyter and Python, terminal scripts, internal services, and automation workflows. If a tool can make an HTTP request, it can query your dataset. That delivers the properties the critique reserves for "true" semantic layers:

• No vendor lock-in. Metric definitions are accessible via API, not trapped inside a proprietary UI. You invest in the semantic layer knowing it stays portable.
• Single source of truth. Define a metric once and query it everywhere, instead of rebuilding the same logic in each tool and watching the numbers drift ("why is revenue different here?").
• Portable and expressive at once. The JSON you get back is computed by AQL, so external consumers receive nested aggregations and cross-grain ratios, not a lowest-common-denominator subset. Holistics also exposes an MCP Server, so AI agents query the governed layer and generate AQL rather than raw SQL.

So the "trapped in a proprietary tool" and "does not serve external tools or agents" claims do not hold.

So, is Holistics a semantic layer? Yes. It is a governed, code-defined layer of composable metrics that is expressive enough to answer questions most layers push into workarounds, and open enough to serve those metrics over an API to whatever consumes them. The more useful question is "does this layer answer my hardest questions natively, keep one definition of every metric, and let any tool or agent query it?"

Judge Holistics, and every tool in this guide, on that.