Lightdash vs dbt Semantic Layer vs Atlan's Context Layer

Austin Kronz

Director, Data and AI Strategy

Updated:08/11/2026

Published:08/11/2026

20 min read

Watch Context Layer Live Get the Context Layer Ebook

Key takeaways

Lightdash and dbt Semantic Layer both govern metric math well, each inside its own tool boundary.
Atlan is an OSI launch partner; the initiative standardizes metric format, not ownership or access policy.
dbt Semantic Layer already serves metrics headlessly to multiple BI tools; the gap sits outside that reach.
Atlan's context layer certifies one metric definition across every tool and agent that consumes it.

How do Lightdash, dbt Semantic Layer, and Atlan's context layer compare?

Lightdash is a BI-native semantic layer that reuses dbt's metric definitions inside one dashboard tool. dbt Semantic Layer is a headless, API-served metrics layer built on MetricFlow that serves one metric definition to Tableau, Power BI, and other downstream tools. Both govern metric math well inside their own boundary. A context layer sits above both, attaching ownership, certification, and access policy to a metric once, so the definition holds wherever it's queried, from a dashboard, a second BI tool, or an AI agent.

Where each one actually operates:

Lightdash: YAML metric definitions reused inside one BI tool, built for teams already living in dbt.
dbt Semantic Layer: headless metrics served via API to Tableau, Power BI, Sheets, and notebooks.
Atlan's context layer: ownership, certification, and policy rules for a metric once it leaves either tool.
What neither tool tracks: which definition wins when a second BI tool or agent disagrees.
The open standard: Atlan helped launch OSI, which standardizes the format metrics are written in, not who owns them.

How aligned are your metric definitions across tools?

Get the Gap Calculator

Lightdash, dbt Semantic Layer, and Atlan’s context layer are three different answers to the same underlying question: where does a metric’s definition actually live? Lightdash answers it inside one BI tool. dbt Semantic Layer answers it inside one dbt project, served headlessly to several tools. Atlan’s context layer answers a narrower, adjacent question: once a metric is defined, who owns it, whether it’s certified, and how that definition survives contact with every other tool and agent touching the same data.

The fragmentation problem behind all three is real enough that more than a dozen competing vendors, Atlan included, organized a joint initiative to fix it. In 2025, Snowflake, Salesforce, dbt Labs, Atlan, and a wider coalition of BI and AI vendors launched the Open Semantic Interchange (OSI) Initiative to standardize the format a metric definition is written in, so it travels intact between tools instead of getting redefined in each one. 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 with a YAML-based semantic layer	Headless, API-served metrics layer built on MetricFlow	Governed layer for metric ownership, certification, and policy
What it does	Defines and visualizes metrics inside one dashboard tool	Serves one metric definition to many downstream tools	Attaches ownership, freshness, and access rules to a metric
Who owns it	The BI/analytics team running Lightdash	The data team maintaining the dbt project	Data governance, platform, and AI teams jointly
Key strength	BI-native reuse of dbt’s existing metric definitions	One definition served headlessly to Tableau, Power BI, Sheets	Consistency once a metric leaves the tool that defined it
Best for	Teams already in dbt who want fast BI reuse	Teams whose metric needs to travel to multiple tools	Teams running more than one BI tool or agent on the same data
Questions it answers	“What does this metric mean in this dashboard?”	“What does this metric mean, wherever it’s queried?”	“Who owns this metric, and can I trust this copy of it?”
Cost/effort to adopt	Free, open-source; low effort if already on dbt	Included with qualifying dbt Cloud tiers; moderate setup	Additive; layers on existing BI and semantic-layer 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’s workflow, reading directly from a dbt project’s YAML files. dbt Semantic Layer defines them headlessly inside one dbt project, served to multiple downstream tools through an 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 OSI itself was scoped to leave it open. Gartner predicts that by 2030, universal semantic layers will be treated as critical infrastructure “alongside data platforms and cybersecurity.” In 2025, Snowflake, Salesforce, dbt Labs, Atlan, and a wider coalition of BI and AI vendors jointly launched the Open Semantic Interchange Initiative as a vendor-neutral YAML standard so any BI tool can consume the same metric definition. Atlan helped build that standard as a launch partner, not as an outside party working around it. More than a dozen vendors that would otherwise compete for this territory agreeing on a shared format anyway is itself evidence the fragmentation is structural, not a framing this page needs to argue into existence.

Standardizing the format a metric is written in doesn’t standardize who’s allowed to change it, which is why confusion persists anyway. Teams that layer Lightdash and dbt Semantic Layer on top of existing BI tools, without addressing that gap, often trade one fragmentation problem for several smaller ones: consistent inside the new tool, still contested everywhere else. Semantic layers failed, and context graphs are next makes an independent version of this argument. That’s a different question 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. The rest of this page treats Lightdash and dbt Semantic Layer as genuinely different, useful answers to where a metric lives, and Atlan’s context layer as the answer to a later question: what happens once that metric is out in the world.

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, Co-founder of Lightdash, describes what a semantic layer needs to contain: “business definitions for every metric; how entities relate to each other; what calculations are meaningful vs nonsense; examples of correct vs incorrect analysis.” Lightdash’s own case for building an open semantic layer argues that BI tools have historically hidden this logic inside proprietary configuration, and that reading it straight from dbt keeps it version-controlled and portable, a different approach from a semantic layer built as a metadata layer on top of a catalog.

Lightdash is active and fast-growing, not a stalled project: its GitHub repository shows 6,028 stars and a push on the day this page was researched, with recent pull requests adding a verification footer and safeguards for server-side agent runs. That same growth surfaces the boundary any BI-native semantic layer eventually meets: Lightdash’s public GitHub issues include reports of duplicate filters on repeated MCP queries, metric metadata stored only in YAML, and open requests to trace which dashboards depend on a table through MCP. Those aren’t signs of a broken product. They’re what happens when a semantic layer built for one tool’s dashboards also has to serve a fast-moving MCP integration: the friction shows up at the tool’s own boundary first.

Core components of Lightdash’s semantic layer

YAML metric definitions: metrics and dimensions are defined as version-controlled YAML inside the dbt project itself, not a separate proprietary format.
dbt model integration: Lightdash reads a dbt project’s existing models directly, so a metric change in dbt updates what Lightdash shows without a second edit.
Dashboards built on those definitions: charts query the same metric logic dbt already defines, rather than a duplicated calculation.
An emerging MCP and agent access layer: early AI integrations let agents query Lightdash’s metrics, which is also where the integration issues above show up.

For Lightdash outside the semantic-layer lens specifically, including pricing and setup, see Lightdash as an open-source BI tool.

What is dbt Semantic Layer?

dbt Semantic Layer is a headless, API-served metrics layer built on MetricFlow, designed to define a metric once inside a dbt project and serve that single definition to multiple downstream BI tools, spreadsheets, and notebooks. dbt Core, the open-source engine underneath it, is also an active, healthy project: its GitHub repository shows 13,617 stars, more than twice Lightdash’s, and a push on the same day this page was researched. Jason Ganz, Director of Community and AI at dbt Labs, frames the value plainly: “by defining metrics centrally in dbt, data teams can trust that business logic referenced anywhere will be exactly the same everywhere.” Served through an API rather than embedded in one tool’s configuration, the same “revenue” definition reaches Tableau, Power BI, and Google Sheets without being redefined in each one, per dbt Labs’ own introduction to the Semantic Layer. That headless reach is dbt Semantic Layer’s real strength over a BI-native layer like Lightdash’s: it already solves cross-tool metric calculation consistency for every tool connected to its API.

dbt Labs is pushing this positioning hard following its Fivetran merger. dbt Labs cites a 2026 finding from Cloudera and Harvard Business Review Analytic Services that only 7% of enterprises say their data is completely AI-ready, and frames Semantic Layer as one of four pillars in an “agentic data stack,” alongside contracts and tests, an AI-authoring assistant, and dbt State. Ganz has also argued that structured, centrally-defined metrics beat direct text-to-SQL for LLM queries, since a query engine that already knows what “revenue” means fails differently than one guessing at raw SQL.

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 query engine: translates a metric request into the correct SQL against the warehouse, wherever it’s asked from.
Headless API serving: metrics are exposed through an API rather than a single tool’s interface, which is what lets one definition reach many tools.
BI-tool integration surface: Tableau, Power BI, Google Sheets, and notebooks connect to the same served definition instead of each building their own.

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 Stack

What is Atlan’s context layer?

Atlan’s context layer is where a metric’s ownership, certification status, freshness, and policy rules live once, across every tool and agent that consumes it, rather than inside any single dashboard or dbt project (the shorter definitional version of this same idea). It doesn’t build dashboards or calculate metrics itself; that work belongs to Lightdash and dbt Semantic Layer. The Enterprise Data Graph is the mechanism: it ingests metric definitions from both BI-native semantic layers like Lightdash and headless ones like dbt Semantic Layer, then attaches the ownership, lineage, and policy rules that neither tracks on its own.

This matters more every quarter because AI agents multiply the number of consumers per metric faster than any single semantic layer can track: a metric that used to have two or three known readers now has Lightdash, dbt’s own MCP server, Tableau, a notebook, and one or more agents all potentially asking for “revenue” at once. To be precise about scope, Atlan’s context layer doesn’t compete with Lightdash for dashboard-building or with dbt Semantic Layer for transformation-time calculation; it answers a question upstream of both.

Core components of Atlan’s context layer

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 underlying table.
Lineage back to the source transformation: traces a certified metric back to the dbt model or pipeline step that produces it.

This is the layer behind why AI agents need an enterprise context layer in the first place, covered in more depth at what is the enterprise context layer and in the context layer glossary.

How do Lightdash, dbt Semantic Layer, and Atlan’s context layer actually compare?

Lightdash, dbt Semantic Layer, and Atlan’s context layer diverge most on scope and stakeholder, and converge on one thing: none of them alone tells a second tool or agent which of several competing definitions to trust. The table below maps six dimensions, including one honest limitation for each party rather than only the ones that flatter it.

Dimension	Lightdash	dbt Semantic Layer	Atlan’s context layer
Primary focus	Dashboards and charts on top of dbt models	Headless metric serving across many tools	Ownership, certification, and policy for any metric
Native query/dashboard capability	Yes, full BI dashboarding	Yes, via MetricFlow’s query engine	No; governs definitions, doesn’t calculate or visualize them
Scope/boundary	One BI tool	One dbt project’s definitions, served via API to many tools	Every tool and agent that touches the data
Ownership & certification	Not tracked separately from the YAML definition	Not a native MetricFlow concept	Explicit ownership and certification status per metric
Failure mode	A second BI tool or agent bypasses Lightdash entirely	A tool outside dbt’s API surface still defines its own version	Depends on adoption; a consumer that bypasses it never sees the certified version
Alignment with OSI	Not a named launch partner	Founding OSI member (with Snowflake, Salesforce, Atlan, and others)	Founding OSI member; extends the format it helped standardize with ownership, certification, and access policy

Consider a common scenario: revenue operations defines “net revenue” in Lightdash with a refund adjustment that a separate finance team’s dbt Semantic Layer model doesn’t include, since that MetricFlow model predates the policy change. Both tools are working correctly; neither knows the other’s definition exists, which is the mismatch Atlan’s Enterprise Data Graph is built to surface so a data owner can certify one answer going forward.

Doesn’t the Open Semantic Interchange Initiative already solve this?

Not entirely, and Atlan has a direct stake in saying so: Atlan is itself a launch partner of OSI, alongside Snowflake, Salesforce, dbt Labs, and a wider coalition of BI and AI vendors, formed in 2025 to standardize the format a metric definition is written in: a vendor-neutral YAML schema so any BI tool can read the same file instead of maintaining an incompatible one. Google Cloud reports that a governed semantic layer already cuts natural-language query errors in Looker by as much as two-thirds, a real, separate benefit of getting semantics right.

What OSI doesn’t do, by design, is assign ownership, certification, access policy, or freshness once multiple tools read that shared format. That’s a deliberate scope line the working group drew, not a gap Atlan is pointing out from outside it. Forrester analysts Boris Evelson, Indranil Bandyopadhyay, Charlie Dai, and Noel Yuhanna argue that enterprises need to build meaning through semantics before agentic AI can be trusted, calling the semantic layer “the right starting point,” not the finish line. It’s a “yes, and,” not a “no”: Atlan’s Enterprise Data Graph ingests a metric’s definition regardless of format, OSI-standardized or a tool’s own native schema, and adds the ownership layer that OSI’s own spec leaves for a layer like Atlan’s context layer to build on top.

For the closest adjacent comparisons, 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.

How do Lightdash, dbt Semantic Layer, and Atlan’s context layer work together?

Lightdash, dbt Semantic Layer, and Atlan’s context layer aren’t mutually exclusive. Most enterprises running more than one BI tool combine at least two of them, and the combinations are complementary, not redundant. This is also where semantic layer for AI agents and the broader systems of semantics framing become relevant: an agent doesn’t care which tool defined a metric, only whether the answer it gets is the trusted one.

Lightdash + dbt Semantic Layer: BI-native reuse of dbt’s metric definitions

Lightdash reads metric YAML directly from the same dbt project that powers dbt Semantic Layer’s API. Lightdash contributes a dashboard-native interface for analysts who don’t want a separate query layer; dbt Semantic Layer contributes the same definition served headlessly to every other connected tool. Combined outcome: one metric definition, visualized in Lightdash and queried by everything else through the same API.

dbt Semantic Layer + Atlan: certifying MetricFlow’s definitions with ownership and lineage

Atlan’s Enterprise Data Graph ingests MetricFlow’s metric definitions and attaches ownership, certification, and lineage back to the transformation producing them, the same mechanism behind turning a semantic definition into governed context. dbt Semantic Layer contributes the served, headless definition; Atlan contributes who approved it and whether it’s still current. Combined outcome: any tool consuming dbt’s API also gets a trust signal MetricFlow doesn’t natively carry.

Lightdash + Atlan: resolving what happens when Lightdash’s definition diverges from a second tool or agent

Atlan ingests Lightdash’s YAML-defined metrics alongside definitions from other tools and agents touching the same warehouse. Lightdash contributes the BI-native definition analysts already trust; Atlan contributes the cross-tool visibility to catch a second, conflicting definition before it reaches a dashboard or an agent. Combined outcome: Lightdash keeps doing what it does well, and stops being the only place a metric’s definition is checked.

Start with Lightdash if you’re dbt-native and want fast BI reuse; dbt Semantic Layer if the metric needs to travel headlessly; Atlan’s context layer alongside either once more than one tool or agent already consumes the same data.

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 Assessment

How 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 dbt model, or a well-built Lightdash dashboard, without a governed business definition above it, is still incomplete context: the transformation can be correct and the metric can still mean two different things in two different tools, the argument made in more depth at context layer for data analytics teams: fixing metrics and the broader case for what is context engineering.

The certified definition from Atlan’s Enterprise Data Graph is what gets exposed through the Atlan 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.

The practical distinction: Lightdash and dbt Semantic Layer answer “what does this metric mean,” each inside a boundary they already own well. Atlan’s context layer answers “can I trust this specific copy of it,” a question that only gets sharper as more agents ask it. See how to implement an enterprise context layer for AI and how to build an AI agent harness 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

Watch Now →

"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

Watch Now →

Get the Context Layer ROI Calculator

Estimate what metric inconsistency across BI tools and agents is actually costing your team today.

Calculate the ROI

Workday is building its shared semantic layer on Atlan and exposing it to AI agents through MCP, the same “one definition, many consumers” pattern this page argues for, regardless of whether that definition originated in a Lightdash-style BI tool or a dbt-style headless layer. DigiKey’s framing of Atlan as 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: Lightdash inside one dashboard tool, dbt Semantic Layer across every tool connected to its API. The Open Semantic Interchange Initiative, which Atlan helped launch alongside Snowflake, Salesforce, dbt Labs, and a wider coalition, is standardizing the format that math gets written in, which helps, and still isn’t the same as deciding who owns a metric once it’s out. That ownership, certification, and provenance question is what survives contact with every tool and agent 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. Whichever combination of Lightdash and dbt Semantic Layer your team already runs, start by reading where your own context layer maturity actually stands before assuming either tool alone has the mismatch covered.

Book a Demo

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 who want BI-native reuse of dbt’s models. dbt Semantic Layer is headless: it serves one metric definition, via MetricFlow, to Tableau, Power BI, Google Sheets, and other downstream tools. Lightdash solves reuse inside one dashboard tool; dbt Semantic Layer solves reuse across many.

2. What is a governed semantic layer?

A governed semantic layer is a metric layer where a definition carries ownership, certification status, and access rules, not just a calculation. Most semantic layers define metric math well; governance adds who approved the definition, who can query it, and whether it’s still fresh.

3. Why use dbt Semantic Layer?

dbt Semantic Layer lets a team define a metric once, inside the dbt project where the transformation logic already lives, then serve it through an API to any connected BI tool or notebook. That removes the need to redefine the same metric’s calculation in every downstream tool separately.

4. How does Lightdash integrate with dbt?

Lightdash reads metric and dimension definitions directly from a dbt project’s YAML files and turns them into dashboards without a separate modeling step. Updating a metric’s definition in dbt updates what Lightdash shows, rather than requiring a second edit inside the BI tool.

5. Does dbt Semantic Layer work with dbt Core?

dbt Semantic Layer depends on MetricFlow, which is built into dbt Core’s metric and semantic model definitions, so the underlying metric logic works with dbt Core. Serving those metrics through the Semantic Layer’s API to external BI tools is a separate, dbt-Cloud-hosted capability on top.

6. Does the Open Semantic Interchange Initiative solve metric fragmentation on its own?

Not on its own, and Atlan (a launch partner of the initiative alongside Snowflake, Salesforce, and dbt Labs) says so about a standard it helped build. The Open Semantic Interchange Initiative standardizes the vendor-neutral format a metric is written in, so more BI tools can read the same file. By design, it doesn’t assign who owns a metric, whether it’s certified, who’s allowed to query it, or whether it’s still fresh once multiple tools consume it. That’s a separate layer built on top of the format, not a shortfall in it.

7. Is a semantic layer enough for a company’s AI agents?

It’s necessary but not sufficient. A semantic layer gives an agent a consistent metric to query, but not whether that definition is the current, approved one, or what a second agent on a different semantic layer would get for the same question, which is where a context layer has to step in.

8. What’s the most common mistake teams make when adopting a semantic layer tool?

Assuming that once a metric is defined in one semantic layer, every other tool and agent touching the same data automatically respects it. A metric defined in Lightdash’s YAML or dbt’s MetricFlow only holds inside that tool’s boundary; a second BI tool or an agent querying the raw warehouse can still produce a different number for the same name.

Sources

Share this article

Atlan is the Context Layer for AI. It attaches ownership, certification, and policy rules to a business's metrics, definitions, and data so every tool, dashboard, and AI agent that queries them gets the same trusted answer, in one continuously updated Enterprise Data Graph.

Book a Demo Context Studio Live