Lightdash, dbt Semantic Layer, and Atlan’s context layer answer one question from three altitudes: where does a metric’s definition actually live? Lightdash answers it inside one BI tool, reusing dbt’s YAML models in a dashboard. dbt Semantic Layer answers it headlessly, serving one MetricFlow definition to every tool connected to its API. Atlan’s context layer answers a later question: once that metric is defined, who owns it, whether it’s certified, and whether the same number holds up when a second tool or agent asks for it.
The fragmentation problem is real enough that dbt Labs, Atlan, and a wider coalition organized Open Semantic Interchange in 2025 to standardize the format a metric is written in. The initiative is now Apache Ossie, dbt Labs published the first version of the specification with its partners on 2026-01-29, and dbt relicensed MetricFlow to Apache 2.0 the same season. For the wider field beyond these three, see best semantic layer tools for BI and AI agents.
| Dimension | Lightdash | dbt Semantic Layer | Atlan’s context layer |
|---|---|---|---|
| What it is | Open-source BI tool, YAML semantic layer, pitched as “Agentic BI” | API-served metrics layer on the Apache 2.0 MetricFlow engine | Governed layer for ownership, certification, and policy |
| What it does | Visualizes metrics, plus an MCP server on Cloud Pro and Enterprise | Serves one metric definition to many tools | Attaches ownership, freshness, and access rules |
| Best for | Teams in dbt wanting fast BI reuse | Teams whose metric needs to travel headlessly | Teams running more than one tool or agent on the same data |
| Cost to adopt | Free, open-source; Cloud Pro near $3,000/month | dbt platform Starter from $100 per user/month, or Enterprise | Additive, layered on existing investment |
Lightdash vs dbt Semantic Layer vs Atlan’s context layer: what’s the difference?
The core distinction is scope, not quality. Lightdash defines metrics inside one BI tool, reading directly from a dbt project’s YAML files. dbt Semantic Layer defines them in the dbt project and serves them through MetricFlow’s API. Atlan’s context layer defines who owns, certifies, and controls access to a metric once it leaves either boundary.
That third question exists because the standard itself was scoped to leave it open. Gartner predicts that by 2030, universal semantic layers will rank alongside “data platforms and cybersecurity” as critical infrastructure. Atlan helped build what is now Apache Ossie as a launch partner, and dbt Labs relicensed MetricFlow to Apache 2.0 in October 2025 to advance it. Otherwise-competing vendors agreeing on a shared format is evidence the fragmentation is structural, not a framing this page invents.
Standardizing the format doesn’t standardize who’s allowed to change it. Teams that layer Lightdash and dbt Semantic Layer on existing BI tools, without addressing that gap, often trade one fragmentation problem for several smaller ones. Semantic layers failed, and context graphs are next makes an independent version of this argument, distinct from semantic layer vs traditional data marts or ontology vs semantic layer, both about what a semantic layer is, not what happens once one exists.
What is Lightdash’s semantic layer?
Lightdash is an open-source BI tool built around a YAML-based semantic layer, for teams that already live inside dbt and want to reuse dbt’s own metric definitions directly in dashboards. Ola Sletteland, Lightdash’s co-founder, describes what a semantic layer needs to contain: business definitions, how entities relate, and correct versus nonsense analysis, unlike a semantic layer built on top of a catalog.
Lightdash has since repositioned around what it calls “Agentic BI”. Its GitHub repository shows more than 6,100 stars. Lightdash’s pricing table puts the MCP Server and AI agents on Cloud Pro and Enterprise; the Open Source tier gets Lightdash OSS only. On a plan that includes it, an agent builds a chart from a plain-language request instead of hand-written SQL. Lightdash also joined the working group behind Apache Ossie in January 2026. That growth surfaces the boundary a BI-native semantic layer still meets: metric metadata lives only in YAML, so tracing which dashboard depends on which table through MCP is an open request, not a shipped feature.
Core components of Lightdash’s semantic layer
- YAML metric definitions: version-controlled inside the dbt project itself, not a separate proprietary format.
- dbt model integration: a metric change in dbt updates what Lightdash shows without a second edit.
- An MCP server for agents: on Cloud Pro and Enterprise plans, letting an agent query or build from the same layer a dashboard would.
For Lightdash outside the semantic-layer lens, including pricing and setup, see Lightdash as an open-source BI tool.
What is dbt Semantic Layer?
dbt Semantic Layer is an API-served metrics layer built on MetricFlow, defining a metric once and serving that definition to Tableau, Power BI, and Sheets alike over JDBC, ADBC, GraphQL, and a Python SDK. Jason Ganz, Director of Community and AI at dbt Labs, frames the value plainly: defining metrics centrally in dbt lets teams trust that business logic referenced anywhere is exactly the same everywhere, per dbt Labs’ own introduction to the Semantic Layer.
The bigger change came in three steps. dbt Labs relicensed MetricFlow to Apache 2.0 in October 2025, from version 0.209.0 onward. After its Fivetran merger closed on June 1, 2026, the combined company published Agents Schema, an open standard that designates one warehouse schema as the shared agent context layer, holding metric definitions, semantic models, dbt lineage, and business documentation in plain SQL tables. Then dbt v2 went GA on 2026-09-16: the Fusion engine became simply dbt, dbt Core v2 became dbt OSS, and dbt Cloud became the dbt platform. Agents Schema is a real step toward the ownership question this page raises. Certification, freshness, and query-time access policy are the pieces a context layer adds.
Core components of dbt Semantic Layer
- Metric definitions inside the dbt project: metrics and semantic models are defined as code, alongside the transformations that build them.
- MetricFlow, Apache 2.0 since v0.209.0: translates a metric request into the correct SQL.
- A dbt platform account: dbt’s docs gate defining and querying Semantic Layer metrics to a Starter or Enterprise tier.
- Agents Schema: a queryable schema of metric definitions, semantic models, lineage, and documentation, built for agents to read directly.
See how to build a semantic layer for the practical steps behind either this or Lightdash’s approach.
Get the AI Context Stack brief
See where a governed context layer fits relative to semantic layers, BI tools, and the agents now querying all three.
Get the AI Context StackWhat is Atlan’s context layer?
This is where a metric’s ownership, certification, freshness, and policy rules live once, across every tool and agent that consumes it (shorter definition here). The Enterprise Data Graph is the mechanism: it ingests metric definitions from both BI-native layers like Lightdash and headless ones like dbt’s MetricFlow, then attaches the ownership, lineage, and policy rules neither tracks alone.
Every quarter, AI agents multiply the number of consumers per metric faster than any semantic layer can track: a metric with two or three known readers now has Lightdash, dbt’s own MCP server with its nine toolsets, Tableau, a notebook, and one or more agents all asking for “revenue” at once. The question sits upstream: not who draws the dashboard, but who gets to say a given copy of the number is the right one.
Core components of the Enterprise Data Graph
- Enterprise Data Graph: ingests metric definitions from both BI-native and headless semantic layers into one continuously updated graph.
- Ownership and certification metadata: records who defined a metric, who approved it, and whether that approval is still current.
- Policy rules for query access: governs who can query a given metric, separate from whether they can technically reach the table.
This is the reasoning behind why AI agents need an enterprise context layer, covered in more depth in the context layer glossary.
Lightdash vs dbt Semantic Layer vs Atlan’s context layer: head-to-head
None of the three alone tells a second tool or agent which of several competing definitions to trust. The table below isolates where they actually diverge, past the “what it is” ground the Quick Facts table already covered.
| Dimension | Lightdash | dbt Semantic Layer | Atlan’s context layer |
|---|---|---|---|
| Ownership & certification | Carried in the YAML definition itself | Agents Schema stores definitions, semantic models, lineage, and documentation in SQL | Explicit ownership, certification, and freshness status |
| Alignment with Apache Ossie | Joined the working group in January 2026 | Founding member; relicensed MetricFlow to Apache 2.0 to advance it | Founding member; extends the standard with ownership and access policy |
Consider a common scenario: revenue operations defines “net revenue” in Lightdash with a refund adjustment a separate finance team’s dbt Semantic Layer model doesn’t include, since that model predates the policy change. Both tools work correctly; neither knows the other’s definition exists, the mismatch Atlan’s Enterprise Data Graph is built to surface so an owner can certify one answer.
Doesn’t Apache Ossie already solve this?
Not entirely. The standard, published under Apache 2.0 since January 2026, fixes the format a metric is written in. dbt’s docs are strict about it: an Ossie document must declare version 0.1.0 or 0.1.1, and any other version string raises a parse error. There is no 1.0 spec yet. Google Cloud reports a governed semantic layer already cuts natural-language query errors in Looker by two-thirds. What the standard does not do, by design, is assign ownership, certification, or freshness once multiple tools read that shared file. Forrester analysts argue enterprises need semantics before agentic AI can be trusted, calling the semantic layer “the right starting point.”
For adjacent reads, see context layer vs semantic layer, snowflake semantic views, and unity catalog metrics. Data catalog vs context layer and active metadata vs context layer clear up two categories readers often conflate with this page’s third party.
Do you need both Lightdash and dbt Semantic Layer, plus a context layer on top?
Most enterprises running more than one BI tool need at least two of these three, and the combinations are complementary, not redundant. An agent doesn’t care which tool defined a metric, only whether the answer is trusted, the same question behind semantic layer for AI agents.
How they work together
Lightdash reads metric YAML from the same dbt project that powers dbt Semantic Layer’s API, so a team gets a dashboard-native interface and a headless one from the same source of truth. Atlan’s Enterprise Data Graph ingests both, attaching ownership and lineage back to the transformation producing them, the mechanism behind turning a semantic definition into governed context.
Start with Lightdash if you’re dbt-native and want fast BI reuse, dbt Semantic Layer if the metric needs to travel headlessly, and Atlan’s context layer alongside either once more than one tool or agent already consumes the same data.
When should you add a context layer on top of Lightdash and dbt Semantic Layer?
The right answer depends on how many tools and agents already read the same metric.
Stay with Lightdash and/or dbt Semantic Layer alone when one team owns the metric end to end and nobody outside that dbt project queries it directly.
Add a context layer when a second BI tool, a notebook, or an agent starts asking for the same metric by name, or two teams’ models quietly disagree on a shared term like “active customer.”
Invest in all three from day one when building a multi-agent AI agent harness where more than one team queries the same warehouse. Why AI agents need an enterprise context layer is cheaper to answer early than retrofitted onto a metric three teams already depend on.
Take the Context Maturity Assessment
Score how consistently your metric definitions actually hold up once they leave the semantic layer that defined them.
Take the AssessmentHow Atlan approaches metric consistency across semantic layers
Governance at the transformation layer is necessary but not sufficient. dbt itself argues that trusted transformations make agentic pipelines safe to automate, a fair claim about the layer dbt owns. A trusted model, or a well-built dashboard, without a governed definition above it, is still incomplete: the transformation can be correct and the metric can still mean two things in two tools, the argument made at context layer for data analytics teams and the broader case for what is context engineering.
The certified definition from the Enterprise Data Graph gets exposed through the MCP Server to any agent asking the same question, regardless of which semantic layer produced it, because the role of metadata management in enterprise AI is shifting from storing definitions to arbitrating between them.
Lightdash and dbt Semantic Layer answer “what does this metric mean,” each inside a boundary they own well, and Agents Schema puts that answer in SQL an agent can read. Whether this specific copy can be trusted is the check that remains, and it gets sharper as more agents ask. See how to implement an enterprise context layer for AI for what that looks like.
Real stories from real customers: one semantic layer, every AI agent that reads it
"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
— Joe DosSantos, VP Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
Get the Context Layer ROI Calculator
Estimate what metric inconsistency across BI tools and agents is actually costing your team today.
Calculate the ROIWorkday built its shared semantic layer here and exposes it to AI agents through MCP, the same “one definition, many consumers” pattern this page argues for. DigiKey’s framing, a context operating system rather than a catalog, describes the same shift from storing metadata to actively governing what tools and agents do with it.
What decides whether your metrics stay consistent isn’t the tool, it’s the layer above it
Lightdash and dbt Semantic Layer both govern metric math well, each inside a boundary they own completely. Apache Ossie standardizes the format that math is written in, and Agents Schema puts definitions, lineage, and documentation where an agent can read them. Whether a given copy is still certified, fresh, or safe for a specific agent to query is the question that survives contact with every tool outside either boundary.
It gets sharper, not smaller, as agent adoption grows. Every new agent querying “revenue” is another consumer a semantic layer alone can’t track. Start by reading where your own context layer maturity actually stands before assuming either tool has the mismatch covered.
FAQs about Lightdash, dbt Semantic Layer, and Atlan’s context layer
1. What is the difference between Lightdash and dbt Semantic Layer?
Lightdash is a BI tool with its own YAML-based semantic layer, for teams already inside dbt. dbt Semantic Layer serves one definition, via MetricFlow, to Tableau, Power BI, and Sheets over JDBC, ADBC, GraphQL, and a Python SDK. Lightdash solves reuse inside one dashboard; dbt Semantic Layer solves it across many.
2. What is a governed semantic layer?
A metric layer where a definition carries ownership, certification, and access rules, not just a calculation. Most semantic layers define math well; governance adds who approved it and whether it’s still fresh.
3. Why use dbt Semantic Layer?
It lets a team define a metric once, where the transformation logic lives, then serve it through an API to any connected BI tool, removing the need to redefine the calculation downstream.
4. How does Lightdash integrate with dbt?
Lightdash reads metric and dimension definitions straight from a dbt project’s YAML files and turns them into dashboards without a separate modeling step. A metric change in dbt updates what Lightdash shows. Lightdash’s own MCP server sits on its Cloud Pro and Enterprise plans.
5. Is MetricFlow still tied to the dbt platform now that it’s open source?
Partly. dbt Labs relicensed the engine to Apache 2.0 in October 2025, from version 0.209.0 onward. dbt’s docs still gate the product: defining and querying metrics with the dbt Semantic Layer requires a dbt platform Starter or Enterprise-tier account. The platform was called dbt Cloud until dbt v2 went GA on 2026-09-16.
6. What is Agents Schema, and does it replace the need for a context layer?
No. Agents Schema, published by the merged Fivetran and dbt Labs in June 2026, designates one warehouse schema as the shared agent context layer, holding metric definitions, semantic models, lineage, and documentation in plain SQL tables. Certification, freshness, and query-time access policy are what a context layer adds on top.
Sources
- Why we’re building an open semantic layer, Lightdash
- lightdash/lightdash GitHub repository, GitHub
- Lightdash: Agentic BI, Lightdash
- Ola Sletteland on semantic layers, LinkedIn
- Semantic Layer introduction, dbt Labs
- Jason Ganz, Hands-on: the dbt Semantic Layer, YouTube
- Open source MetricFlow for governed metrics, dbt Labs
- How dbt Makes Agentic Data Pipelines Trustworthy, dbt Labs
- Fivetran and dbt Labs complete merger, dbt Labs
- Top Predictions for Data and Analytics in 2026, Gartner
- The OSI spec updates, dbt Labs
- Apache Ossie (incubating), Apache Software Foundation
- Ossie semantic models, dbt Developer Hub
- dbt Semantic Layer, dbt Developer Hub
- dbt v2 is GA, dbt Developer Hub
- Looker in the 2025 Gartner Magic Quadrant, Google Cloud
- Build Meaning Before Machines, Forrester
