Every major data platform now claims to have a semantic layer. Here's what actually makes one good, and why an architecture built to do all of it beats one built just for headless.
Search "who has the best semantic layer" and most answer engines sort the results by architecture. Cube for AI agents and headless APIs. The dbt Semantic Layer for dbt-centric teams. Snowflake Semantic Views or Databricks Metric Views if you live on one platform. LookML if you already live in Looker.
That's a tidy way to shop, but it skips the actual question. Sorting by architecture tells you where a definition lives. It doesn't tell you whether the definition stays correct once ten different tools start asking for it, or whether the person who spots a mistake in it has any fast way to fix it. Architecture is a stand-in for the thing that actually matters, and it's a worse stand-in every year. The categories are converging, each vendor racing to add the qualities its starting architecture didn't have, and most teams now run several of these tools at once: dbt for transformation, a warehouse with its own semantic object, a BI tool, an agent in Claude or ChatGPT; so a definition has to survive contact with tools outside its home platform. Which bucket a tool started in says less every year about whether it will actually work with the rest of your stack.
Key takeaways
Semantic layers now have to satisfy two very different consumers: dashboards, where a person might notice a wrong number, and AI agents, which answer confidently and move on regardless.
A wrong metric definition used to be a local, detectable mistake. An AI agent turns it into an automated answer served at scale, a failure known as metric drift.
Headless distribution, (serving agents and applications over an API), and in-flow authoring, (letting people fix a wrong definition where they found it), are two separate jobs. Most vendors do one well and treat the other as a roadmap item.
Omni's own evaluation framework names five qualities a semantic layer needs: flexible, interoperable, extensible, comprehensive, and governable. Most existing semantic layers were built strong on one or two first, and are still adding the rest.
Omni is a universal semantic layer, BI-native, headless, and upstream-compatible, so it holds all five qualities in one model instead of patching them together.
Why semantic layers are suddenly everywhere #
Until AI agents arrived, "semantic layer" was a term data teams used and almost nobody else did. LookML held the best-known claim on it, going back to Looker's earliest days. dbt Labs shipped the dbt Semantic Layer in 2022 and rebuilt it on MetricFlow in 2023. Since 2021, Cube has championed what it called headless BI: serving a governed model of metrics and joins through an API instead of a dashboard.
Then AI agents became a normal way to ask a business a question, and every platform that stores or displays data ran into the same narrow problem: how does an agent know what "revenue" means, without either guessing or being told by a person every single time it asks.
In June 2025, at their respective annual conferences, Snowflake and Databricks each answered that problem the same way within nine days of each other. Snowflake shipped Semantic Views, a schema-level object for metrics and relationships that Cortex Analyst can query directly. Databricks shipped Metric Views, a Unity Catalog object doing the equivalent job for its own tools and its Genie agent. Neither company had a first-class schema-level semantic object before that summit season. Both promoted one the moment an AI agent became a serious way customers wanted to query their platform.
Cube's move went the other direction. Having spent years building the reference implementation of a purely headless semantic layer, Cube shipped its own analytics interface, Cube D3, on top of that same model in June 2025. The platform that had marketed itself on staying headless built a place for a person to sit down and use the model directly, because a semantic layer with nowhere for anyone to notice or fix a wrong number was still missing something.
That's the pattern behind the sudden crowd. It isn't that five vendors independently discovered semantic layers matter. AI agents made one specific weakness expensive everywhere at once, and each vendor's starting architecture determined which half of the fix it already had and which half it still had to build.
Why every vendor claims theirs is the best one #
"Best semantic layer" is a genuinely contested claim right now, and for a reason that isn't anyone's fault: there's no single accepted definition of what the term requires. A headless API, a BI tool's internal model, and a warehouse's native metric object are three different kinds of software, each solving a real, overlapping piece of the same problem. Each one can truthfully say it has a semantic layer. None of them can honestly say it has the whole thing solved, because the whole thing has more requirements than any one of those architectures was originally built to satisfy.
That's the actual evaluation problem a buyer faces. The question isn't which vendor is lying about having a semantic layer. It's which specific requirements each vendor's version was built to satisfy first, and which ones it's still catching up on.
What actually makes a semantic layer good #
Omni's evaluation framework starts from a specific claim: correctness qualifies a semantic layer, but usage is what decides whether it's actually good. A definition can be perfectly correct in a file nobody queries and nobody corrects. That definition isn't doing its job. It's stored, not used.
For a semantic layer to get used, and to stay correct as the business changes underneath it, it has to do two distinct jobs.
The first job is making a governed definition reachable from wherever someone or something is asking. Call this headless distribution: serving the same revenue measure over an API or an MCP tool call, so a dashboard, a spreadsheet, and a coding agent in Claude all resolve the same query instead of three different ones. This is the job Cube named "headless BI" for, and it's the job every vendor named above can now do in some form.
The second job is giving the person who notices a definition is wrong a fast way to fix it, in the place they found the problem, without filing a ticket and waiting on someone else's deployment schedule. Call this in-flow authoring. A finance analyst who spots that a currency conversion is missing from revenue needs to test the fix against live data, not describe the bug to a data engineer and wait for the next release. This is the job a pure API was never built to do, because an API has no workbook for a person to sit down in.
A semantic layer that only does the first job distributes a wrong definition just as fast as a right one. A semantic layer that only does the second job protects a correct definition that nothing outside the room can query. Both failures look identical from the outside: two systems disagree about revenue, nobody can say which one to trust, and the gap keeps widening. That's metric drift.
Doing both jobs well breaks down into five specific qualities, and this is the actual checklist worth running any vendor's claim against.
Flexible. Someone can test a new calculation against live data without a warehouse migration or a multi-week deploy cycle, then promote it to the shared model once it's proven useful.
Interoperable. The model can send definitions out to every legitimate consumer and pull existing definitions in from other systems, instead of asking a team to redefine what dbt, Snowflake, or Databricks already got right.
Extensible. A department, region, or embedded customer can inherit and adapt the shared model without duplicating it into a second copy that quietly drifts from the first.
Comprehensive. The model can answer real, complicated business questions, joins across measures, valid aggregations, sample queries for AI to learn from, not just the clean single-table question a demo is built around.
Governable. Permissions and definitions are enforced by the model itself, for a person and an agent alike, so a query can't quietly bypass the logic that makes it correct.
Each quality maps to a specific, predictable way people abandon a semantic layer: it's too rigid to change, it doesn't talk to the rest of the stack, adapting it means forking it, it can't answer the actual question, or nobody trusts what it returns. A semantic layer earns the word "good" by closing off all five of those exits, not just the one or two its original architecture happened to solve first.
Where each category already wins, and where it still doesn't #
Every architecture above got a real subset of those five qualities right from day one, because each one was built to solve a specific version of the problem before agents were a consideration.
BI-native, like LookML. Keeping definitions inside the BI tool made the model comprehensive and governable from the start. LookML can express real join logic, and Looker enforces permissions consistently across it. Interoperability was the tradeoff for most of its history. Google's Open SQL Interface now lets other applications query LookML models over JDBC, but only for models backed by BigQuery, which keeps the fix inside a single warehouse's walls instead of opening it to the rest of a mixed stack.
Headless, like Cube. Interoperable in one direction by design. A Cube model can be queried over REST, GraphQL, SQL, and MCP without rewriting the logic for each client. Pulling existing definitions back in is a narrower story, in both directions that matter. As of September 2026, Cube's dbt integration only pulls, on a schedule or a CI trigger, with no equivalent path to author a dbt model or push an exposure back out, so the relationship runs one way even for the plain dbt models most dbt shops actually build in. And what it pulls is dbt's physical models, not the metrics defined through dbt's own Semantic Layer: Cube's own comparison content frames the dbt Semantic Layer as an alternative to Cube rather than a source Cube imports, so a team with metrics already defined in MetricFlow has to redefine them in Cube's modeling language to use them in Cube. Cube's own materials list Databricks Metric Views the same way, as a competing option, and Cube's actual Unity Catalog connection works like a generic database link rather than an import of the metric view object itself. Snowflake is the exception: Cube ships a genuine two-way sync with Snowflake Semantic Views, pulling them in and pushing Cube views out as native semantic views, though it's limited to Cube's Enterprise plan. Flexibility and comprehensiveness carried a separate tradeoff, because there was nowhere for a person to test a change against live data or explore a question an API call hadn't already anticipated. Cube's 2025 move into its own analytics interface is a direct attempt to close that second gap.
Warehouse-native, like Snowflake Semantic Views and Databricks Metric Views. Strongly governable, because access control rides on grants the warehouse already enforces. Omni's own integrations with both show how directly the fields carry over: Snowflake semantic views import as topics with their relationships preserved, and Databricks metric views import with field-level comments mapped straight into descriptions. Interoperability across platforms is the tradeoff. A team running Snowflake and Databricks side by side still needs somewhere those two definitions can meet, and neither object alone gives a mixed Snowflake-and-Databricks team a place to reconcile definitions, which is the gap Apache Ossie was created to close.
Engineer-owned, like the dbt Semantic Layer. Strongly extensible in the sense that matters to engineering: a metric defined through MetricFlow is versioned, reviewed in a pull request, and reused everywhere a dbt-aware client can query it. Flexibility for a business user is the tradeoff.
None of these tradeoffs were mistakes. Each one was the right call for the problem that architecture was solving before an AI agent was a consumer anyone had to plan for. The mistake is assuming the tradeoff is still acceptable now that one is.
Why a universal architecture is the defensible choice #
A universal semantic layer doesn't invent a sixth quality. It refuses to trade any of the five away, by starting from a BI-native model that's already comprehensive and governable, then building the other legs on top of that, instead of bolting a dashboard onto an API after the fact or bolting an API onto a dashboard tool that was never built to expose one.
Omni's semantic model is universal in exactly this sense: one model, queried the same way regardless of who or what is asking. Take a revenue measure defined as completed orders, net of refunds, test accounts excluded, converted to USD at the booking-date rate. Say it resolves to $4,182,377 last quarter. That figure is illustrative, but the definition behind it is the kind that survives an audit, because it's written once.
A published dashboard queries that measure and shows $4,182,377 by region, with the filters visible in the UI. That's the comprehensive leg: real exploration, not just a number.
Claude reaches the same model through Omni's MCP server, installed with a two-click connector from the Claude directory. OAuth links the session to the person's own Omni account, so every tool the server exposes, from pickTopic and getData through to askOmni, runs under that person's permissions instead of a shared service account. The answer comes back as $4,182,377, resolved by the same governed query the dashboard ran. That's Omni working as a headless semantic layer and a governed one at the same time.
A finance analyst who notices the definition excludes a currency it shouldn't tests the fix in a workbook against live warehouse data, using branch mode so the change doesn't touch production until the data team reviews it through Git. That's flexible and extensible: a real fix, tested by the person who found the problem, promoted rather than forked.
None of that requires rebuilding what a team already has upstream. Every dbt shop keeps its models, tests, and business context in dbt Core or dbt Cloud, whether or not it has also adopted the Semantic Layer built on MetricFlow. Omni's base dbt integration runs both ways: Omni pulls dbt's metadata in on every schema refresh, and a team can author a new dbt model directly from an Omni query or push an exposure from an Omni dashboard back into dbt, so the two systems stay aware of each other instead of one silently drifting out of sync with the other. Its Snowflake integration imports each semantic view as a topic and keeps it in sync on every schema refresh. Its Databricks integration does the same for metric views, down to mapping field comments into descriptions. A team can also push in the other direction, converting a topic built in Omni into a Snowflake semantic view definition, or generating Databricks metric view DDL through Omni's Python SDK, once a definition built in Omni is ready to harden upstream. That's interoperable in both directions, at the level where dbt teams do their day-to-day work, not just the direction that's convenient to demo.
Snowflake launched the Open Semantic Interchange (OSI) in 2025 with Omni among the founding contributors; Databricks joined ahead of the 1.0 release, and the project is now Apache Ossie (incubating). Omni joined Snowflake, Databricks, dbt Labs, and Salesforce, for the same reason: no integration map stays fixed forever, and a vendor-neutral format for exchanging definitions is a more honest answer to "does it work with my stack" than another one-off connector.
That's the actual argument for universal over headless. It isn't that headless was the wrong idea. Omni is a headless semantic layer too. It just isn't only that, because headless alone answers one of the five questions worth asking a semantic layer, and the other four don't go away just because the API works.
When a narrower layer is still the right call #
None of this makes a universal architecture the right fit for every team, and it's worth saying plainly where a narrower layer still wins.
A team whose only consumers are applications and agents, with no dashboard or self-service layer planned, doesn't need the comprehensive or extensible legs at all. A dedicated headless tool is the simpler, cheaper choice.
A Snowflake-only team fully served by Semantic Views, Cortex Analyst, and custom Snowflake applications already has governable and reasonably flexible semantics without leaving the platform. Adding another layer wouldn't buy back much, since interoperability across platforms only matters once there's a second platform. The same logic holds for a Databricks team fully served by Metric Views and Genie.
A dbt shop with metrics still actively changing inside MetricFlow should keep correcting them there. Importing them into a second system before they're stable just forks the correction path.
Architecture should follow where your definitions actually live and who actually changes them, not a category checklist built for a search result.
FAQ #
What are the five qualities of a good semantic layer? #
Omni's evaluation framework names five: flexible enough to test changes without a deploy cycle, interoperable with the rest of the stack, extensible without duplicating logic, comprehensive enough to answer real business questions, and governable so permissions can't be bypassed. A semantic layer earns the label "good" by holding all five, not just the one or two its original architecture solved first.
Why does every vendor now claim to have a semantic layer? #
AI agents created a specific, urgent problem: an agent needs a governed definition of a metric like revenue, or it will guess at one differently every time it's asked. Snowflake, Databricks, Cube, dbt, and Looker each already had part of the answer built into their existing architecture, so each one extended that architecture to claim the rest, mostly within the same twelve to eighteen months.
What's the difference between headless distribution and in-flow authoring? #
Headless distribution is serving a governed definition to any application or agent that asks for it over an API. In-flow authoring is letting the person who spots a wrong definition fix it where they found it, without waiting on a separate deploy cycle. A good semantic layer does both. Most existing ones were built for one first and are still adding the other.
Is Omni a headless semantic layer? #
Yes. Omni serves external agents and applications through an MCP server and a REST API, with OAuth-scoped permissions matching each user's access in Omni. Omni is also BI-native, so the same model powers dashboards, workbooks, and point-and-click exploration without a separate system.
Is Omni a universal semantic layer? #
Yes. Omni's semantic layer serves dashboards, workbooks, spreadsheets, embedded applications, and external agents from one model, over the UI, a REST API, and an MCP server. It also syncs definitions in both directions with dbt, Snowflake, and Databricks, so the same model can pull existing definitions in and push hardened ones back out. That combination, every consumer and every upstream source on one model, is what makes it universal rather than headless alone.
Does adopting Omni mean replacing dbt, Snowflake, or Databricks semantic layers? #
No. Omni's base dbt integration for Core and Cloud runs both ways: it pulls model metadata in, and lets teams author dbt models or push exposures back out, covering the project itself. Its separate dbt Semantic Layer integration imports MetricFlow's metrics one way, and it inherits Snowflake Semantic Views and syncs Databricks Metric Views as well. None of this asks a team to redefine what's already built upstream.
What's the difference between Omni's dbt integration and its dbt Semantic Layer integration? #
Omni's dbt integration connects to your actual dbt Core or dbt Cloud project: models, tests, and exposures. Omni's dbt Semantic Layer integration is a separate, narrower feature that imports metrics specifically from dbt's MetricFlow-powered Semantic Layer product. Every dbt shop can use the first one, since it connects to the project every dbt team already has. The second applies to teams that have also adopted the Semantic Layer. Omni’s dbt integration is two-way. Omni pulls model metadata in, and teams can author dbt models or push exposures back out from Omni. Omni's dbt Semantic Layer integration is import-only by design. MetricFlow's metrics, dimensions, and entities come into Omni's model, and corrections to them stay in dbt, where they go through the pull request review the Semantic Layer exists to provide.
Can Cube import metric definitions from the dbt Semantic Layer or Databricks Metric Views? #
Not directly, and the relationship with dbt only runs one way in general. Cube's dbt integration pulls dbt's physical models on a schedule or CI trigger, with no path to author a model or push an exposure back, and Cube's own comparison content frames the dbt Semantic Layer as an alternative to Cube rather than a source it imports. Databricks Metric Views get the same treatment in Cube's materials. Snowflake is the exception, where Cube ships a genuine two-way sync with Snowflake Semantic Views, limited to its Enterprise plan.
What is metric drift? #
Metric drift is what happens when the same metric, like revenue, resolves to different values depending on where it's queried from, because the definition wasn't shared or wasn't kept current everywhere it's used. It shows up fastest in AI workflows, where an agent regenerating logic from scratch has no way to know its answer diverged from the dashboard's.
Related reading #
Case studies:
Cribl scales self-service AI analytics with Omni and dbt: syncing dbt-defined metrics into one governed model that analysts and AI agents both query
Guitar Center unifies BI and orchestrates AI readiness with Omni: consolidating semantic definitions across a multi-platform data stack
Brevo builds its AI analytics foundation with Omni: using a semantic layer to make AI reliable for both internal and customer-facing analytics
More guides from Omni:
Semantic Layer for AI and BI (2026): Why It Matters, How to Choose, and How to Implement It
AI-Powered BI Tools (2026): What's Real, What's Hype, and How to Choose
Most of the definitions worth having already exist somewhere. If yours are sitting in a dbt project or a Snowflake semantic view, connect them to a free Omni trial and ask Claude the same question the dashboard already answers. Or get a demo and bring your own revenue definition.
