6 Open-source Semantic Layers for AI Agents and BI (2027 Edition)

Every semantic layer vendor (opens in a new tab) now describes its product as a semantic layer for AI agents, and the description is fair, because the job of a semantic layer (one definition of revenue that every consumer has to go through) matters more when the consumer is Claude writing SQL than when it was an analyst who knew which table double-counted refunds. The trouble is that the phrase has stopped telling you anything. Cube, dbt, Malloy, Wren and a handful of smaller projects all say it, and they mean quite different things by it: one is a server you deploy, one is a CLI that becomes an API only on a paid plan, one is a Python library, and one is a modelling language with a server bolted on later.

This guide looks into what we consider the best open-source semantic layers on the things that decide whether one of them will work for your team: what you can run for free, how an AI agent reaches it, how a BI tool or an internal app reaches it, how expressive the modelling language is, and how much infrastructure you take on.

The consumer is the agent

A semantic layer built for dashboards had one main customer, the BI tool, and that customer was (usually) patient: a data team configured it once, mapped every field, and the tool sent the same well-formed queries for years. An agent is a different kind of customer, because it arrives with a vague question ("how did revenue do last quarter?"), has to find the right metric among dozens with similar names, and then has to ask for it in a form the layer understands, all without a human checking the mapping.

When the consumer is the agent, choosing an open-source semantic layer gets a bit tricky. Take "semantic search" for example: with most of the semantic layers, requests like “pull me revenue” and “units by month” might fail without a context layer pointing agents to the appropriate metric. When metric or dimension names weren’t clean, the agent could say it couldn’t find something even though the relevant metrics existed.

This is why we think the right way to look at open-source semantic layers is along these five criteria:

1. Where the open-source line sits. A project can be Apache 2.0 and still keep the API your agent needs, the permissions model or the caching layer in a paid product, so the license matters less than the list of what the free edition actually serves.
2. How agents reach it. An MCP server is now table stakes, but the tools behind it vary a lot, from a plain list of metric names that the agent has to search by keyword to search that matches "sales" to a metric called net_revenue.
3. How BI tools and apps reach it. A layer that only serves agents leaves your dashboards on their own definitions, which brings back the drift you adopted a semantic layer to stop, so SQL, REST and SDK access still matter.
4. How expressive the language is. Simple sums and counts work everywhere; period-over-period comparisons, nested aggregates, cohort retention and percent-of-total are where languages start to differ, and they are also the questions business users ask an agent first.
5. What it costs to run. A small data team with no platform engineer will feel the difference between one binary on a small VM and a cluster with a separate caching store.

The short version

	License	Agent access	BI and app access	Runs as	Paid edition adds
anfra (AMQL)	Apache 2.0	MCP server	JavaScript SDK, HTTP API	One Go binary or Docker image	Users, roles and per-user permissions (anfra Cloud, in development)
Cube Core	Apache 2.0	MCP (fuller tool set reported on paid plans)	SQL, REST, GraphQL	Server plus Cube Store for caching	Managed hosting, analytics chat and agents, enterprise access features
dbt MetricFlow	Apache 2.0 (v0.209.0 and later)	dbt MCP server; semantic layer tools call dbt's hosted APIs	Hosted Semantic Layer APIs on a paid dbt plan	Python CLI inside a dbt project	The queryable Semantic Layer API itself
Malloy + Publisher	MIT	Publisher serves MCP	Publisher serves REST	Publisher server	Hosted platform from Credible, the company behind Malloy
Wren Engine	Apache 2.0	MCP server	Engine API, Wren AI UI	Engine inside the WrenAI repo	Row- and column-level security, GenBI UI, agentic mode
Boring Semantic Layer	MIT	MCP extra	Python only	Python library on Ibis	No paid edition

Each row is a summary of the project's own README, docs or announcements as of October 2026.

Cube Core: the most complete, and the heaviest

Cube (opens in a new tab) leads the category on adoption, with around 20,000 GitHub stars, and releases its core as Cube Core under Apache 2.0.

Cube Core serves governed queries over SQL, REST and GraphQL, so existing BI tools connect to it as if it were a Postgres database while your own apps call the REST API. The open-source edition also includes Cube Store, the caching layer whose pre-aggregations keep repeated queries fast on large tables.

Teams that self-host Cube might run into two problems. First, Cube might keep its best features for Cube Cloud: some practitioners said the features they cared about sit in the cloud version, and that the open-source edition feels neglected next to it. Second, Cube might take more work to stand up than a small team expects: it has been reported to feel like a heavy system to set up and manage, far from deploying one service on a VM in a few minutes.

Cube's new positioning might make the first problem grow. Cube now markets itself as an agentic analytics platform, with its own agents and analytics chat in Cube Cloud, so its AI work and its revenue both point at the paid product. One third-party review (opens in a new tab) already reports that the fuller MCP tool set, including editing and publishing the data model, sits on paid plans. If you want your own Claude or ChatGPT seats to do the analysis, test exactly what Core's MCP server exposes before you commit.

Cube fits teams with a platform engineer, several BI tools that need one set of definitions, and data large enough that pre-aggregation matters.

anfra: an open semantic framework for agents to build your own BI

anfra (opens in a new tab) gives coding agents everything they need to build your own BI on governed metrics, under Apache 2.0. anfra includes a semantic layer, but the semantic layer is one component of the framework, not the whole product.

That difference sets anfra apart from every other entry here. The other projects stop once a metric reaches a consumer, so you still need a BI tool to show the numbers, or an engineer to build the app around them. anfra covers the whole path from model to running app:

• Semantic layer. You define models, datasets and metrics as files in your repository in AMQL (opens in a new tab), the analytics-as-code language for an expressive semantic layer. AML defines models and metrics declaratively, and AQL queries them as composable, first-class objects.
• Query server. The server compiles metric requests into SQL for Snowflake, BigQuery, Databricks, Redshift, PostgreSQL, ClickHouse, DuckDB and others. It runs as one Go binary or Docker image, on a laptop or a small VM.
• Agent access. Claude, ChatGPT, Cursor or Codex connect to the MCP endpoint and read the models before they answer.
• App SDK. Apps your coding agent builds ask for revenue by name through the JavaScript SDK, with filters, date drills and cross-filters built in, so the dashboard and the chat use one calculation.
• Agent skills. The skills teach your coding agent to write models and build apps, so the agent drafts definitions as code and your team reviews them in pull requests.
• Inspect. Every number in an app traces back to its metric definition, the query on the page and the SQL that ran.

For finished examples, the data app library collects apps coding agents have built with anfra, from a conversion funnel builder to a headcount and hiring planner.

The open-source edition has no logins or per-user permissions, so expose the server only to people allowed to see all of its data; anfra Cloud, still in development, adds them. anfra reads only AMQL today, and support for dbt, Cube, Snowflake and Databricks semantic layers is planned but not shipped. The app SDK supports JavaScript only, so a team that builds internal apps in Python connects through the MCP server or the HTTP API instead.

anfra fits fast-growing data teams and consultants whose users already ask Claude or ChatGPT their data questions, who want those answers and their internal apps on one set of definitions, and who don't want to run a cluster or buy a BI tool to get there.

dbt MetricFlow: free to define, paid to serve

MetricFlow (opens in a new tab) powers the dbt Semantic Layer, and dbt Labs moved it to Apache 2.0 in October 2025 (versions 0.209.0 onward; earlier versions were AGPL). You define metrics in YAML inside your dbt project, next to the models they read from, so a team that already lives in dbt keeps its semantic definitions in the same repository, pull requests and lineage graph.

YAML, however, is a general-purpose markup language, designed for storing data rather than developing analytics logic. Analysts can now write metrics in it, but the usual developer experience, such as syntax highlighting and autocompletion, is inadequate or absent when they do.

MetricFlow shares the problem of most open-source semantic layers: dbt ties the full experience to dbt Cloud. The open-source part defines metrics and compiles them to SQL from the mf command line. Serving those metrics to BI tools and agents goes through dbt's Semantic Layer APIs, which require a paid dbt plan and charge by query volume, and dbt's open-source MCP server calls those same APIs for its semantic layer tools. Some practitioners reported that using dbt's semantic layer might push a team onto an enterprise plan costing several thousand euros a month.

MetricFlow fits teams already paying for dbt Cloud, or teams willing to treat metrics as a compile step and wire the SQL output into their own tools.

Malloy and Publisher: the most interesting language

Lloyd Tabb, who created LookML, built Malloy (opens in a new tab), an MIT-licensed modelling and query language. Malloy treats nested queries, reusable sources and join-safe aggregates as first-class ideas, so a question that takes a page of window functions in SQL fits in a few lines. It compiles to SQL for DuckDB, BigQuery, Snowflake, PostgreSQL, Trino and others.

Publisher (opens in a new tab), also MIT, serves Malloy models to other tools over REST and MCP. Its ecosystem is younger than Cube's and smaller than dbt's, and a recent comparison (opens in a new tab) notes that Publisher's MCP tools read models but can't write them, so an agent edits .malloy files and reloads. Credible, the company behind Malloy, sells a hosted platform, so check which access-control features you would have to build yourself on the open-source edition.

Malloy fits analytically ambitious teams that value an expressive language over a large ecosystem, and teams already on DuckDB, where Malloy's tooling works best.

Wren Engine: built for text-to-SQL from the start

Wren Engine (opens in a new tab) powers Wren AI, a GenBI product, and its team designed it for AI agents from the start. You write models in Wren's Modeling Definition Language (MDL). The engine and its MCP server are Apache 2.0, and the standalone wren-engine repository now lives inside the main WrenAI repository under core/.

The README draws the open-core line clearly: the engine, the MCP server, the CLI and the MDL semantic layer are open source, while row- and column-level security, the GenBI interface and the agentic mode are commercial. Permissions stop an agent from showing a sales rep someone else's pipeline, so a self-hosted Wren setup for more than a few trusted users means paying or building that layer yourself.

Wren fits teams that want a text-to-SQL product with a semantic layer underneath and are happy to adopt the Wren AI interface along with the engine.

Boring Semantic Layer: the lightest option

Boring Semantic Layer (opens in a new tab), an MIT-licensed Python library, defines dimensions and measures on top of Ibis (opens in a new tab), so it runs on any engine Ibis supports. An optional [mcp] extra exposes the models to Claude and other MCP clients, and pip installs the whole thing.

It ships no server, no permissions model and no API for BI tools, so it suits one analyst or a small team querying a handful of well-defined measures from a notebook or script. Some users question how actively Ibis is maintained now that much of its original team has moved on, so check before you build anything long-lived on it.

Boring Semantic Layer fits Python-first teams and prototypes, and it teaches what a semantic layer does before you choose a heavier one.

Two related options worth knowing

Apache Ossie (incubating) defines a format, not an engine. Snowflake, Salesforce, dbt Labs, BlackRock and RelationalAI started it in September 2025 as the Open Semantic Interchange, and it entered the Apache Incubator in July 2026 (opens in a new tab) under its new name. Its YAML format describes metrics, dimensions and relationships so that definitions can move between tools. Ossie will matter for portability once more engines read and write it, but it runs no queries, so it sits alongside whichever layer you choose.

Warehouse-native semantic layers, such as Snowflake semantic views and Databricks metric views, ship as proprietary warehouse features. They cost existing customers nothing extra and integrate tightly with each vendor's own AI assistant, which makes them the sensible default for a team committed to one warehouse. They also tie your definitions to that platform and leave you stuck if part of your data lives elsewhere.

How to choose

Pick by situation:

• A team with a platform engineer and several BI tools gets the most from Cube Core, which has the widest set of APIs and the strongest caching in an open-source edition.
• A small team whose users already work in Claude or ChatGPT, and who want those agents and their custom apps on one set of definitions without buying a BI tool or running heavy infrastructure, is who we built anfra for.
• A team already on dbt Cloud gets the most from MetricFlow, since the definitions live beside the models and the paid APIs are already in the contract.
• A team that values the modelling language above all should look hard at Malloy, especially on DuckDB.
• A team that wants a ready-made text-to-SQL interface will find Wren closest to a finished product.
• A single analyst prototyping in Python can start with Boring Semantic Layer in an afternoon.

Whichever you pick, a half-day test settles it. Take a modelled dataset, ten real questions your business users asked recently (including at least two with near-duplicate metric names, such as gross and net revenue), and your agent connected over MCP. Adopt the layer that returns the right metric for the most questions with the least prompting from you, then check the paid-edition column in the table above to see what you'll owe once more than a few people depend on it.