If you have ever sat in a meeting where finance says revenue is $14.2M and marketing says it is $15.1M, you know the problem. Same word, same quarter, two completely different numbers. The root cause is almost always the same: business logic is scattered across dozens of BI dashboards, SQL scripts, and spreadsheets, with no single definition anyone can point to and say "this is the truth."
Databricks just took a significant swing at fixing this. Unity Catalog Business Semantics hit general availability in early April 2026, and the company is open-sourcing the core Metric View implementation directly into Apache Spark. That second part is the real headline.
What Business Semantics Actually Does
Think of it like a contract between your data and the humans (and AI agents) consuming it. Instead of burying the definition of "monthly recurring revenue" inside a Tableau calculated field or a dbt model that three people know about, you define it once, at the data layer, in standard SQL.
The mechanism is a new first-class object in Unity Catalog called a Metric View. You write a CREATE VIEW statement with a WITH METRICS clause and a YAML body that declares your measures (aggregations like SUM, COUNT, ratios) and dimensions (the axes you slice by, such as region, product line, or month). It looks something like this:
CREATE OR REPLACE VIEW catalog.schema.revenue_metrics
WITH METRICS LANGUAGE YAML AS$$
version: 1.1
comment: "Revenue KPIs for finance and sales"
source: catalog.schema.orders
filter: order_date > '2025-01-01'
dimensions:
- name: Order Month
expr: DATE_TRUNC('MONTH', order_date)
- name: Region
expr: region_name
measures:
- name: Total Revenue
expr: SUM(total_price)
format: currency
- name: Revenue per Customer
expr: SUM(total_price) / COUNT(DISTINCT customer_id)
$$Once created, a Metric View is queryable from SQL, dashboards, Genie (Databricks' AI assistant), notebooks, and alerts. It inherits Unity Catalog's access controls, lineage tracking, and audit logging automatically. You add semantic metadata like display names, synonyms, and formatting hints so that both human analysts and AI agents understand what they are looking at.
Why the Semantic Layer Matters Now More Than Ever
Semantic layers are not a new idea. Looker built LookML around this concept a decade ago. dbt Labs has its MetricFlow. AtScale, Cube, and others have been in this space for years. But two forces are converging in 2026 that make a governed semantic layer genuinely urgent.
The first is tool sprawl. Research shows that 61% of organizations use four or more BI tools, and 25% use ten or more. Each tool recreates metric definitions independently. Without a shared semantic foundation, you get drift. Slowly, silently, "revenue" starts meaning different things in Tableau than it does in Power BI or in the Python notebook your data scientist wrote last quarter.
The second force is AI agents. When a human analyst builds a dashboard, they carry institutional context in their head. They know that "active users" means DAU for the product team and MAU for the investor deck. An LLM querying your data warehouse does not have that context. Without governed definitions to anchor it, an AI agent will guess, and it will guess confidently and incorrectly. Organizations report up to a 67% reduction in AI query errors when agents work through a semantic layer rather than hitting raw tables directly.
Gartner predicts that by 2027, organizations prioritizing semantics in their AI-ready data infrastructure will improve GenAI model accuracy by up to 80% and cut costs by up to 60%. I believe those numbers might be conservative. In my experience, the biggest cost of bad data is not compute or storage. It is the meetings where people argue about which number is right instead of deciding what to do about it.
The Open-Source Bet
This is where Databricks' move gets strategically interesting. They are contributing the core Metric View implementation to Apache Spark OSS. That means the fundamental mechanism for defining and querying business metrics will be available to anyone running Spark, not just Databricks customers.
Why give away the crown jewels? Because semantic layers follow network effects. A metric definition is only valuable if every tool in your stack can consume it. If Metric Views are locked inside Databricks, competing tools will build their own incompatible semantic formats, and the fragmentation problem just moves up a level. By open-sourcing, Databricks bets that becoming the de facto standard is worth more than the short-term licensing advantage of keeping it proprietary.
Databricks has also joined the Open Semantic Interchange (OSI) initiative, finalized in January 2026. OSI defines a vendor-neutral format for sharing business context between semantic layers and AI consumers. Partners include Snowflake, Salesforce, dbt Labs, Atlan, Alation, Mistral AI, and ThoughtSpot. I see this as a strong signal that the industry is moving past the "my semantic layer vs. yours" phase and toward genuine interoperability.
What the GA Release Includes (and What It Doesn't)
The GA foundation ships with metric governance at its core: access controls and lineage inherited directly from Unity Catalog, plus the open-source Spark implementation for portability. Alongside GA, several features are launching in public preview:
Point-and-click UI in Catalog Explorer for creating Metric Views without writing YAML
Genie Code agentic authoring where an AI assistant helps generate metric definitions from natural language
Materialization with smart query routing (early preview) for pre-computing expensive aggregations
On the roadmap but not yet shipped: deeper BI integrations (Tableau support is expected in late 2026), simplified discovery in the platform UI, and managed MCP (Model Context Protocol) servers that let any MCP-compatible AI agent query governed data through Unity Catalog.
One honest gap worth noting: Business Semantics today covers metrics and governance well, but the broader semantic surface (entity classification, ontologies, named relationships, knowledge graphs) is still early. Teams that need those deeper modeling capabilities will likely need to layer additional tooling on top for now.
What This Means for Data Teams
If you are running a data platform on Databricks (or on Spark in general), this is worth paying attention to immediately. The practical implications break down along a few lines:
Audit your current metric definitions. Before migrating anything, inventory where business logic lives today. In dbt models? Tableau calculated fields? Custom SQL in notebooks? You cannot consolidate what you cannot find.
Start with your highest-contention metrics. Revenue, churn, active users, whatever metric generates the most "which number is right?" debates in your organization. That is where a single governed definition delivers the fastest ROI.
Evaluate the open-source angle seriously. If you are running Spark outside of Databricks, the open-source Metric View implementation gives you access to the same semantic primitives without a platform commitment. That is genuinely new and reduces the switching cost of adopting a semantic layer.
Think about AI readiness. If you are deploying or planning to deploy AI agents that query your data, a semantic layer is not optional. It is the difference between an agent that gives your CFO a confident wrong answer and one that gives a trustworthy right answer. The semantic layer market is projected to grow from $2.7B in 2025 to $7.7B by 2030 for exactly this reason.
The Bottom Line
Databricks open-sourcing its semantic layer implementation is a bet that the metrics definition problem is too important to solve inside a walled garden. I think they are right. The semantic layer has been a missing piece of the modern data stack for years, an idea everyone agreed was important but nobody standardized at the foundation layer.
With Business Semantics going GA, Metric Views landing in Apache Spark OSS, and the OSI initiative bringing competitors to the same table, we are finally getting close to a world where "revenue" means the same thing regardless of which tool is asking the question. For data teams drowning in metric inconsistency (and honestly, that is most of them), this is the most consequential infrastructure shift in the analytics layer since dbt mainstreamed the transformation layer.
The real test will be adoption. Standards only win when people actually use them. But the open-source play gives this one a genuine shot.
Written by
Bruno Bonando
Fractional CTO and technology advisor. 23+ years shaping platforms for many companies across Europe and Latin America. Has had leadership roles at REWE, MediaMarktSaturn, Cazoo, and some others.
