Build vs Buy a Semantic Layer: Real Costs and How to Decide

---

Four things decide build vs buy for a semantic layer: tools served, who runs the service, how the price grows, and exit cost. Every option leaves the metric definitions with your team, so a head of data or data platform lead choosing where metrics live is really choosing what to operate. Atlan, the AI Context Platform, catalogs Databricks metric views and Power BI semantic models as semantic assets today, with more connectors marked coming soon in its documentation. Cataloging maps those definitions to business concepts such as metrics and dimensions, so teams can interpret business logic consistently across tools.

The license fee is rarely the whole cost. Every model still needs people to agree on definitions, assign owners and settle disputes. Buying changes who runs the service. Deciding what “active customer” means stays with you.

Question	Short answer
When to build	Metric computation is part of your product, or no product meets your security rules
When to bundle	One warehouse or BI platform will serve most consumers for the next two years
When to buy	Two or more tools, applications or agents need the same definitions
Open-source engines	MetricFlow (Apache 2.0) and Cube Core (Apache 2.0 backend, MIT client)
Entry managed prices (Nov 11, 2026)	dbt Starter $100 per user per month; Cube Starter $40 per developer per month
What stays yours in every model	Definitions, owners, reviews and reconciliation

---

What are you actually building or buying?

A semantic layer pairs business logic with a query service. The logic covers metrics, dimensions and joins; the service turns requests into queries and returns results.

Building the whole thing means running that service yourself: its API, authentication, query planning, caching, BI connectors, monitoring and on-call rotation.

That split also explains the difference between a semantic layer and a metrics layer. A metrics layer focuses on shared calculations, while a semantic layer for analytics also maps dimensions, relationships and access rules. In a large enterprise these pieces become part of wider systems of semantics that have to stay consistent across tools.

Uber’s account of its uMetric platform shows the scale of the job. In a January 2021 post, Uber Engineering described the same metric being defined differently across channels and built one platform to manage each metric’s full lifecycle. It covered six pillars:

• Definition: create and maintain metrics, dimensions and relationships.
• Discovery: help teams find and reuse approved definitions.
• Planning: turn each request into an efficient execution plan.
• Computation: run batch, real-time and backfill calculations.
• Quality: monitor source data and results.
• Consumption: serve metrics through standard interfaces.

Uber built the platform, so it owned all six pillars. Every other model hands some planning, computation and consumption to a product or a provider, and your team keeps definition and most of discovery.

---

What are the six ways to get a semantic layer?

Build versus buy is an ownership decision.

It settles who runs the query service, how you pay, and what changes if you move. The guide to the best semantic layer tools covers individual products; here they are grouped into six models.

Model	Examples	What you run	What you pay	What a move would touch
Homegrown	Uber uMetric, Airbnb Minerva	Definitions and the whole service	Engineering and infrastructure	Custom code and an internal model
Open source, self-hosted	MetricFlow, Cube Core	Definitions, deployment, authentication, scaling, upgrades	Infrastructure and an operating team	The project’s modeling language
Managed	dbt Semantic Layer, Cube	Definitions and metric stewardship	Seats, usage and caching compute	Modeling language and hosted APIs
Warehouse-native	Snowflake semantic views, Databricks metric views	Definitions and platform grants	Platform compute and AI usage	Native platform objects
BI-embedded	LookML, Power BI semantic models	Definitions inside the BI tool	BI licensing	BI platform and its connectors
Dedicated universal layer	AtScale, Honeydew	Definitions	Subscription on the provider’s metering unit	Provider modeling language and query service

Homegrown

A homegrown layer pairs your definitions with a custom query service, API, cache, connectors, monitoring and on-call support. You get full control and a permanent engineering line in the budget.

Open source, self-hosted

The product supplies the compiler and API; your team deploys, secures, scales, monitors and upgrades it. MetricFlow “is distributed under the Apache 2.0 license”, and the MetricFlow license history explains how it got there. Cube Core runs locally or self-hosted with Docker, and its repository lists an Apache 2.0 backend and an MIT-licensed client. The trade-offs of an open-source semantic layer are mostly operational.

Managed

The provider runs the service around an open modeling layer. The dbt Semantic Layer is available on dbt’s Starter, Enterprise and Enterprise+ plans. Cube, the commercial platform built on Cube Core, adds managed deployment, role-based access control, multi-tenancy and BI integrations. The dbt Semantic Layer and Cube comparison covers the differences in depth.

Warehouse-native

Snowflake semantic views became generally available for querying in Snowflake’s 9.25 release (August 2025). A role that does not own a view needs the SELECT privilege on it, per Snowflake’s documentation. Databricks metric views are defined with SQL DDL or in Catalog Explorer with YAML validation. They live in Unity Catalog, where owners control access (Microsoft Learn). Both compute on their own platform.

BI-embedded

Power BI semantic models and LookML keep definitions inside the BI platform, and both reach further than dashboards. Looker’s Open SQL Interface exposes LookML models to any application that supports JDBC, for LookML projects that use a Google BigQuery connection. Does a second BI tool or an agent framework need the same definitions? Then compare a Power BI semantic model with a dedicated semantic layer and LookML with a universal semantic layer first.

Dedicated universal layer

A dedicated layer serves shared definitions to more than one warehouse, BI tool, application or agent. AtScale prices by deployed semantic objects, which its pricing page defines as “the governed metrics, dimensions, and models you publish for production use”. The AtScale and Cube comparison shows how two independent services differ.

All six models leave the metric definitions with your team. Five of them involve buying or bundling something.

---

Where does the money go across the six cost drivers?

Six cost drivers decide total cost, and only some of them appear on a price list.

Every path needs metric owners and compute. Building adds platform operations, and managed services turn part of that work into subscription and usage charges. Public TCO models rest on assumed salaries, team sizes and timelines, so estimate these drivers against your own environment.

Definition authoring and reconciliation

Your team defines each metric and settles disagreements even when it buys the query service. Uber’s inconsistent metrics were a definition problem first. In a July 2021 interview, Robert Chang said Airbnb had been building its Minerva metrics platform since 2017. Budget for owners, reviews and change management.

Platform engineering

Self-hosting a product means operating its compiler, API, authentication, caching, monitoring and upgrades; building means writing them first. Cube’s own README warns that “Development mode is an authentication bypass” and must stay off production, which is one example of the hardening a self-hosted team owns. Open source removes the license fee; production operations remain.

Query engine and caching compute

Every question costs compute. Caching and pre-aggregation cut repeated queries but add processing, storage and refresh costs. Cube’s pricing page lists Cube Store caching at $0.15 per hour per worker on Starter and $0.30 on Premium. On Databricks, refreshing materialized views for metric views “incurs Lakeflow pipelines usage charges” (Microsoft Learn).

Consumer coverage

List every interface you need: SQL, JDBC, DAX, MDX, REST, GraphQL and MCP. Any consumer the layer does not serve becomes connector work. That is why text-to-SQL is not a substitute for a semantic layer: generated SQL gives you neither one definition nor an interface for every consumer.

Access policy

Warehouse-native and BI-embedded models reuse the platform’s permissions. An independent layer has to pass the user’s identity to the source or enforce row- and column-level rules itself. Caches and pre-aggregations need the same rules. Ask where authorization runs and whether it covers every consumer. Rebuilding role-based access control outside the source platform adds implementation and audit work.

Exit cost

A move can mean rewriting definitions, replacing integrations and retesting consumers. Data lineage for AI shows what a move would touch but does not make models portable. Price the modeling language and the query service into the exit as well as the license.

The cheapest license rarely produces the lowest total cost. The next question is how each provider charges for what it runs.

---

What do semantic layers cost across published pricing models?

Semantic layers are priced by users, deployed objects, platform compute or AI usage. The context layer TCO comparison of build, buy and bundle covers the wider infrastructure; this table covers only the semantic engine and managed services.

Published prices

Checked on each vendor’s page on November 11, 2026:

Option	Pricing model	Published pricing
dbt Semantic Layer	Seats plus a queried-metric allowance	Available from the Starter plan. Starter is $100 per user per month with five developer seats and 5,000 queried metrics per month. Enterprise and Enterprise+ are custom-priced with 20,000 queried metrics per month, and Enterprise adds governed metrics with caching.
MetricFlow	Open-source engine	Apache 2.0 license; you pay to run it.
Cube Core	Open-source engine	Apache 2.0 backend and MIT-licensed client; you pay to run it.
Cube	Seats plus managed compute	Free is $0. Starter is $40 and Premium $80 per developer per month; on Premium, Explorer seats are $40 and Viewer seats $20 per user per month. A dedicated deployment is $0.60 per hour on Starter and $1.20 on Premium. Enterprise is custom.
AtScale	Deployed semantic objects	Standard and Enterprise editions, priced by deployed semantic objects. AtScale’s pricing page states “No per-seat or per-query fees”.
Honeydew	User seats plus a platform fee on active objects	Lite is $20 per user per month plus a platform fee from $500 per month; Standard is $30 per user per month plus a platform fee from $2,000 per month. Enterprise is custom.
Snowflake semantic views	Platform and AI consumption	Cortex Analyst bills by messages processed, counting successful responses only, and “Additional warehouse costs apply” when you run the SQL it generates. Snowflake’s documentation recommends transitioning to Cortex Agents.
Databricks metric views	Platform consumption	Queries run on Databricks compute, and materialization refreshes run as Lakeflow pipelines on serverless compute.

How to read the pricing table

Seat pricing rises with users, object pricing with the size of the model, message pricing with agent traffic, and platform-native cost with compute. On Snowflake and Databricks the documented charges sit in AI messages, warehouse time and materialization pipelines. None of these figures cover authoring, reconciliation, integrations, access-policy work or exit costs, which the six cost drivers above estimate.

Compare options on the unit you expect to grow fastest.

---

How should you evaluate the build vs buy decision?

Score the six models against the estate you expect in two years.

A warehouse-native layer may fit one warehouse well. Planned warehouses, BI tools, apps and agent frameworks still belong in the decision now.

Nine criteria to score

Use these nine semantic-layer criteria:

What to evaluate	Build or self-host fits when	Warehouse-native or BI-embedded fits when	Managed or dedicated fits when
Warehouses and engines	One stable engine	One committed platform	Metrics span two or more engines
Consumers and interfaces	A few consumers can use SQL or custom APIs	Consumers use the platform’s own BI and AI tools	Consumers in two or more tools need SQL, DAX, MDX, REST or MCP from one definition
Who defines the metrics	Engineers maintain definitions in Git	Platform analysts work in tools they already use	Engineers and analysts need shared authoring
Query-service operations	A platform team owns security, upgrades, monitoring and on-call	The platform provider runs the service	Your team does not want to run a query service
Performance	You can tune caching and queries	Existing materialization meets the need	Applications need managed pre-aggregation
Access policy	You can pass identity through or reproduce source rules	Platform permissions can be reused as they are	Identity and rules must carry across systems
Exit tolerance	You accept maintaining or migrating custom code	You accept rewriting definitions if you leave the platform	You need documented import and export
Metering fit	You can fund engineering and infrastructure	You can fund platform compute and AI usage	User, object or platform-fee pricing matches your growth
Agent access	You can build the API or MCP interface	Only the platform’s own agents need metrics	Two or more agent frameworks need supported access

How to weigh the criteria

The criteria are not equal weight. A hard requirement such as DAX clients, an air-gapped deployment, identity passthrough or several engines can rule out an option before price comes up. Broader context layer evaluation criteria and metadata tooling build-vs-buy criteria cover the infrastructure around the engine.

Five questions to answer first

Before comparing vendors or estimating cost, answer five questions:

1. How many metrics are in scope? Count what must be defined, reviewed, tested and maintained.
2. How many domains have a named owner? Record who approves definitions and where ownership is unresolved.
3. Which consumers need which protocol? Map dashboards, spreadsheets, applications and agents to SQL, JDBC, DAX, MDX, REST, GraphQL or MCP.
4. How many compute engines will you run in two years? Include planned warehouses and platforms.
5. How does each option’s cost grow? Note whether it scales with users, objects, platform fees, agent messages, compute or headcount.

A worked example

Here is how the answers play out for one common estate: one cloud warehouse, dbt for transformation, Power BI for most dashboards, and two agent frameworks on the roadmap. Dashboards point to keeping Power BI models. The two agent frameworks and the planned engines point to a managed or dedicated layer that serves the same definitions over SQL and MCP. That points to a mix, with one place where owners approve each definition.

Questions to ask vendors

Put the same questions to every shortlisted option and ask to see each answer working in a demo:

1. Which interfaces does the layer serve today (SQL, JDBC, DAX, MDX, REST, GraphQL, MCP), and which of your consumers use each one?
2. Where does authorization run, and do caches and pre-aggregations respect row- and column-level rules for each user?
3. What is the billing unit, what is included, and what happens when you go over it?
4. Can you export every definition in a documented format, and what is lost on the way out?
5. Who runs upgrades, monitoring and on-call, and what support level comes with your plan?

Red flags

Watch for these during evaluation:

• A demo that only shows one BI tool when your estate has several consumers.
• Access rules that hold in the warehouse but are bypassed by the cache or a service account.
• A price quote with no stated billing unit or overage rule.
• No written export path for definitions.
• A proof of concept with no named owner for the metrics being tested.

---

When does building, bundling, or buying win?

Each path wins under a specific set of conditions, and an estate can meet more than one set at once.

When does building win?

Build when metric computation is part of the product you sell, or when no managed or self-hosted option meets your security rules. The team must already run production data services. It must also be ready to support the query service for years.

When does bundling win?

Bundle when one warehouse or BI platform will serve most consumers for the next two years. It is the fastest start. It gets harder to stretch once another engine or tool needs the same metrics.

When does buying win?

Buy when two or more tools or agents need the same definitions and your team does not want to run a query service. Managed caching and protocol support you would otherwise build also point to buying.

Why is a mix common?

Domains adopt platforms at different times. If finance defines revenue in Power BI while the platform team defines it in the warehouse, you are running two semantic layers whether you planned to or not, and the work becomes keeping both definitions consistent and owned.

---

What do AI agents need beyond the semantic layer?

A semantic layer tells an agent how a metric is calculated, and on its own platform it runs under that platform’s permissions.

Snowflake checks the SELECT privilege on a semantic view, and Unity Catalog governs metric views. Once definitions span platforms, owners, approval status, quality signals and policy rules sit in different places. That gap separates semantic layers built for BI from those serving AI agents.

Raw schemas are hard for agents. In the Spider 2.0 paper (2024, revised 2025), a code agent built on o1-preview solved 21.3% of 632 enterprise tasks, against 91.2% on Spider 1.0. Its databases often hold more than 1,000 columns, and tasks require searching metadata and dialect documentation. The benchmark measures difficulty rather than a remedy. A semantic layer for AI agents removes part of that guesswork by handing the agent approved logic.

Before an agent uses a metric, it needs:

• Who owns the metric, and which definition applies to this user’s domain.
• What produced the number, and whether those inputs passed their checks.
• Which data and metrics the requesting identity may see.
• How it retrieves definitions and context, for example through MCP and the semantic layer.

This is the gap behind the argument that semantic layers fail without surrounding context. A context layer, a data catalog and a semantic layer each do a different job. So do context engineering and a semantic layer, and an ontology and a semantic model.

---

What does Apache Ossie change about lock-in, and what does it not change?

Apache Ossie reduces lock-in on the definition format. The rest of the stack stays where it is.

Snowflake announced Open Semantic Interchange on September 23, 2025, with partners including Salesforce, dbt Labs, BlackRock and RelationalAI; Atlan was among the coalition named. On July 10, 2026 the project entered the Apache Incubator as Apache Ossie. According to the Apache Ossie announcement, the YAML-based format for metrics, dimensions and relationships is unchanged. The coalition has grown from 17 launch partners to more than 50 organizations. The explainer on Open Semantic Interchange covers the spec in detail.

Adoption is early. The Ossie converters repository registers 23 converter projects, with explicit capability skips. In dbt, Ossie documents require dbt v1.12 and spec version 0.1.0 or 0.1.1, and unsupported metric types or constructs are dropped with a warning.

Ossie carries definitions between systems that support the same features. The rest stays behind: query services, caching, APIs, integrations, access rules, owners, approvals, lineage and quality checks. Each has to be rebuilt or re-pointed on a move. That is a separate problem, closer to context portability.

---

How Atlan approaches the build vs buy decision

Atlan treats the semantic engine and the context around it as two decisions.

Pick the engine on your estate, interfaces, operating capacity, performance and cost. Once definitions span warehouses, BI tools and semantic services, treat owners, approvals, lineage and policy as a separate layer. The same split shows up in Snowflake Horizon Context and the Atlan context layer.

The engines compute the numbers; Atlan helps people and agents pick the right definition:

• Atlan’s documentation lists Databricks metric views and Power BI semantic models as supported semantic assets, with more connectors marked coming soon.
• Context Engineering Studio reads SQL queries, BI dashboards and other systems of record, drafts a semantic layer for domain experts to refine, runs evaluations against it, and ships it as a versioned context repository for AI agents.
• Context Agents do the reconciliation work. Sage finds where two teams define the same metric differently and routes the conflict to stewards, Nexus links technical column names to business terms, and Orion maps what each term means in each context. Humans stay ON the loop: stewards approve before a definition changes.
• Data Lineage builds column-level provenance from SQL, pipelines and APIs, and Databricks metric views are among the assets it tracks, so you can see which dashboards and models a definition change touches.
• Context Lakehouse serves that context through MCP, A2A, SQL over Iceberg, and REST and Graph APIs.

The enterprise context layer is where those pieces meet. A context layer pilot should test one domain end to end: its engine, owners, access rules, lineage and agents.

---

Real stories from real customers: Shared definitions reaching AI agents

Two Atlan customers describe what it takes to get one set of business definitions in front of AI agents.

---

Which pillars will your team own?

Of Uber’s six pillars, decide which you want to run and which you would rather rent.

Definitions and owners stay with you in every model. So the real comparison is operations, metering and exit cost against your two-year estate.

If agents are part of that estate, plan for the context around each definition as well as the engine that computes it. The AI Context Stack brief compares four types of context infrastructure, semantic layers included, and helps you decide which one your AI use cases need first.

---

FAQs about build vs buy semantic layer

Short answers to the questions data leaders ask most often when they price a semantic layer.

1. Should we build or buy a semantic layer?

Build only when metric computation is part of your product or no product meets your security requirements. Bundle when one platform serves most consumers. Buy when two or more tools or agents need shared definitions and you do not want to run a query service.

2. How much does it cost to build a semantic layer in-house?

There is no reliable published average. Budget for engineering, infrastructure, definition authoring, reconciliation, integrations, monitoring and on-call support. Airbnb started building its Minerva metrics platform in 2017, and Uber’s uMetric covered six platform pillars, from definition to consumption.

3. Is the dbt Semantic Layer free?

MetricFlow, the engine behind it, is open source under Apache 2.0. The hosted dbt Semantic Layer is available on the Starter, Enterprise and Enterprise+ plans. As of November 11, 2026, Starter costs $100 per user per month, and Enterprise plans are custom-priced.

4. Is Cube open source?

Cube Core is open source, with an Apache 2.0 backend and an MIT-licensed client that teams can self-host with Docker. Cube is the company’s commercial platform built on Cube Core, adding managed deployment, role-based access control, multi-tenancy and BI integrations.

5. What does Snowflake charge when AI reads semantic views?

Cortex Analyst bills by the number of messages processed, counting only successful responses, and running the SQL it generates adds warehouse costs. Snowflake’s documentation recommends transitioning to Cortex Agents, so check that service’s billing too.

6. Can I move metric definitions between semantic layers?

Partly. Apache Ossie gives definitions a vendor-neutral format, but support varies. dbt v1.12 reads Ossie spec versions 0.1.0 and 0.1.1 and drops unsupported constructs with a warning. Query behavior, integrations and access rules have to be rebuilt on the new platform.

7. Do AI agents need a semantic layer?

Agents that answer metric questions benefit from one, because approved logic, dimensions and relationships reduce what they must infer from raw schemas. They also need each definition’s owner, approval status, lineage, quality and access rules, delivered through an interface such as MCP.

8. Can we run more than one semantic layer?

Yes. If several platforms each define metrics, such as a warehouse, a BI tool and a dedicated service, you are already running more than one. Named owners, shared reviews and cross-platform context keep those metrics from drifting apart.

9. Does a context layer replace a semantic layer?

No. A semantic layer defines and calculates metrics. A context layer connects those definitions to owners, approval status, lineage, quality, domain meaning and access rules, then delivers that context to tools and agents.

10. Who should own the semantic layer?

Two groups share it. A platform team runs the query service, its access rules and its upgrades, whichever model you choose. Domain owners, such as finance for revenue, approve what each metric means and settle disputes. Name both before you pick a product.

11. Do you need a semantic layer yet?

You need one once two or more tools, teams or agents report the same metric and get different numbers. If one BI tool serves almost everyone and nobody disputes the numbers, the semantic model inside that tool may be enough for now.

12. How do you measure whether a semantic layer is working?

Track a few plain counts over time: metrics with a named owner, conflicting definitions still open, consumers reading from the shared definitions instead of their own SQL, and time to approve a change.

13. What should the first 90 days of a semantic layer project look like?

Pick one domain with a known metric dispute. Name its owners, define its top metrics once, connect the two or three consumers that matter most, and test access rules and cache behavior for real users. Expand only after that domain’s numbers match everywhere.

---

Sources

1. The Journey Towards Metric Standardization, Uber Engineering
2. Ep 1: Robert Chang on Scaling Metrics @ Airbnb, The Analytics Engineering Roundup
3. About MetricFlow, dbt Developer Hub
4. dbt Semantic Layer, dbt Developer Hub
5. Apache Ossie semantic layer documents, dbt Developer Hub
6. dbt Pricing, dbt Labs
7. cube-js/cube repository, GitHub
8. Cube Pricing, Cube
9. Pricing, AtScale
10. Pricing, Honeydew
11. Querying semantic views, Snowflake Documentation
12. 9.25 Release notes, Snowflake Documentation
13. Cortex Analyst, Snowflake Documentation
14. Manage metric views, Microsoft Learn
15. Materialization for metric views, Microsoft Learn
16. Open SQL Interface, Looker Documentation
17. Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows, arXiv
18. Snowflake, Salesforce, dbt Labs, and More, Revolutionize Data Readiness for AI with Open Semantic Interchange Initiative, Snowflake
19. Apache Ossie (Incubating): The New Name for Open Semantic Interchange, Apache Ossie
20. apache/ossie-converters repository, GitHub
21. Semantic offerings by connector, Atlan Documentation