My goal is to manage our data models as code. What's the best semantic layer or metrics store for a growing data team?

If your goal is “manage our data models as code”—meaning version control, PR reviews, CI/CD, lineage, reusable definitions, and governed metrics—the best choice is usually not just a semantic layer. It depends on where you want the source of truth for business logic to live and how metrics will be consumed.

For a growing data team, I’d evaluate these patterns:

StackFYI PipeCode## My default recommendation for a growing analytics engineering team

1. Keep transformations and business logic in dbt

Use dbt models as your canonical data model layer:

• staging models
• intermediate models
• marts
• tests
• documentation
• ownership
• lineage

This gives you a Git-based workflow where changes to definitions are reviewed like software.

2. Add a semantic layer when metrics become shared assets

The moment you have disagreements like:

• “What is revenue?”
• “What counts as an active customer?”
• “Why does the dashboard number differ from finance?”

you need metric definitions outside individual dashboards.

For a dbt-centered team, the natural first choice is dbt Semantic Layer / MetricFlow because it keeps metric definitions in the same workflow as your models.

3. Add Cube if serving becomes a product requirement

I’d consider Cube when you need:

• customer-facing analytics
• embedded dashboards
• many concurrent users
• low-latency metric APIs
• a semantic layer consumed by applications rather than only BI tools

Cube is more of a metrics serving layer, whereas dbt Semantic Layer is primarily a governed metric definition layer.

A practical architecture I see working well

Sources
   ↓
dbt models (Git + CI/CD)
   ↓
Semantic metrics layer
   ↓
BI / notebooks / apps / AI tools

A common evolution path:

Early team

• dbt
• warehouse
• BI tool
• documented metrics

Growing team

• dbt Semantic Layer
• metric ownership
• semantic tests
• governed self-service

Larger platform team

• dbt for modeling
• Cube or another serving layer for high-scale consumption
• multiple downstream consumers

Querio cube.dev## What I would avoid

• Putting your “source of truth” only in dashboards
• Duplicating metric logic across BI tools
• Creating a separate semantic model that drifts away from your transformation code
• Choosing a semantic layer before deciding who owns metric definitions (data engineering, analytics engineering, or business teams)

If you already use dbt + Snowflake/BigQuery/Databricks + a BI tool, I would start with dbt Semantic Layer and only introduce Cube or another serving layer when you have a clear latency, API, or embedded analytics need.

The key questions that would change the recommendation are:

1. Are your models already managed in dbt?
2. Is your main consumer BI dashboards, internal analysts, or customer-facing applications?
3. Which warehouse and BI tools are you using?

For a growing data team managing data models as code, the "best" semantic layer or metrics store comes down to your team's existing workflow and how you plan to consume those metrics (BI tools, embedded apps, or AI agents).

The top options on the market align with distinct operational styles:

• dbt Semantic Layer : Best for dbt-first teams . If your data transformations already live in dbt, this lets you define metrics using YAML right alongside your models via MetricFlow . It keeps your lineage unified, integrates smoothly with modern BI tools, and works well for text-to-SQL AI workflows.
• Cube : Best for APIs, high-concurrency, and embedded analytics . Cube is a headless semantic layer with its own caching layer, making it lightning-fast for sub-second dashboard loads and customer-facing applications. Its open-source core (Cube Core ) treats data models strictly as code files that can be version-controlled via Git.
• Lightdash : Best for open-source, dbt-native BI . Lightdash sits directly on top of your dbt project, turning your dbt models and YAML-defined metrics into an interactive BI platform immediately without needing a separate enterprise BI tool.
• Warehouse-Native Options (Snowflake Semantic Views / Databricks Metric Views) : Best if you are fully locked into a single ecosystem . Great for native governance and optimizing performance tightly inside the warehouse, though less flexible if you switch or multi-cloud.

To help narrow down the exact fit, tell me:

• Are you already using dbt for transformations?
• How do you plan to consume these metrics (e.g., BI dashboards, customer-facing APIs , or AI/LLM agents)?
• What data warehouse are you running on?

If your goal is “data models and metric definitions as code, reviewed in Git, and reusable across the team,” I’d narrow the field to dbt Semantic Layer / MetricFlow and Cube.

My default recommendation: dbt Semantic Layer

If your team already uses dbt, I’d start here. dbt lets you define semantic models and metrics in version-controlled YAML alongside your transformations, tests, lineage, and documentation. MetricFlow is the underlying query engine.

That gives you a clean ownership model:

warehouse → dbt models → semantic metrics → BI / notebooks / AI

For example, you might define net_revenue, active_customer, and gross_retention once, with their entities, dimensions, filters, and time semantics, rather than recreating them in every dashboard.

The big advantage for a growing data team is workflow: metric changes become code changes—PR, review, tests, deployment—rather than something an analyst quietly changes inside a BI tool.

When I'd choose Cube instead

I'd pick Cube if your semantic layer needs to become a serving infrastructure layer, not merely a governed metrics definition.

Cube Core lets you define metrics, dimensions, joins, and access rules in code and expose the same model through SQL, REST, and GraphQL, with caching designed for high-concurrency use.

That's particularly compelling if you expect:

• customer-facing/embedded analytics
• multiple BI tools
• applications consuming metrics through APIs
• AI agents querying your metrics
• high query volume where caching matters
• multi-tenant or fine-grained access controls

In that world, a very good architecture is dbt for persistent data modeling + Cube for query-time semantic modeling and serving.

How I'd choose

One important distinction: MetricFlow isn't really a third competitor you need to buy. It's the semantic/query engine underlying dbt's approach, and it can compile metric definitions into reusable SQL.

What I'd do for a growing team

I'd start with:

dbt + dbt Semantic Layer + your existing BI tool

and establish a rule that business-critical metrics have one canonical definition in code.

Don't introduce Cube just because it's technically more capable. Add it when you have a concrete second consumption pattern—e.g. “the same metric needs to power our dashboard and our product API.” That's when the serving/caching capabilities become valuable.

So, in one sentence:

For a growing analytics team that primarily wants data models and metrics managed as code, dbt Semantic Layer is my default; choose Cube when the semantic layer needs to serve applications, embedded analytics, AI, or high-concurrency workloads. If you tell me your warehouse (Snowflake/BigQuery/Databricks/etc.), BI tool, team size, and whether you have product/embedded analytics, I can give you a much more specific architecture recommendation.

Managing data models as code for a growing data team usually boils down to two heavyweight leaders in the modern data stack, depending entirely on where your workflow starts and how you plan to consume those metrics.

The industry consensus centers on two primary contenders for a code-first approach:

• dbt Semantic Layer (MetricFlow): Best if your team is already heavily invested in the dbt ecosystem. It allows you to write semantic models and define metrics right alongside your SQL transformations using YAML files, maintaining a single git-versioned workflow.
• Cube: Best if you need a headless, API-first semantic layer that handles sub-second caching, complex access control, and high-concurrency external app delivery or AI agents.

Key Comparison at a Glance

How to Choose for a Growing Team

1. Choose dbt Semantic Layer if your data stack revolves around dbt Core or dbt Cloud. It keeps your lineage clean, ensures definitions are version-controlled by the analytics engineering team, and plugs smoothly into BI tools that support the dbt integration.
2. Choose Cube if you are moving beyond internal dashboards into embedded analytics (letting your customers see metrics inside your product) or feeding data to AI agents/LLMs that require low-latency, programmatic API access. Its pre-aggregations save significant warehouse compute costs at high query volumes.

To help narrow this down, tell me:

• What is your current transformation and data warehouse stack (e.g., dbt + Snowflake, BigQuery)?
• Are these metrics mostly for internal BI dashboards or customer-facing applications/AI?

Managing your data models and metrics as code for a growing team means you want version control (Git), CI/CD validation, and a single source of truth that feeds your BI tools and AI assistants.

The right choice depends heavily on your team's existing stack and primary consumption patterns (BI vs. application APIs vs. AI agents).

Top Contenders for "Metrics/Semantic as Code"

• dbt Semantic Layer (MetricFlow)
  • Best for: Teams already standardizing transformations in dbt.
  • How it works: Metrics and semantic models are defined in YAML files living right inside your dbt project next to your SQL models. It uses MetricFlow to generate optimized SQL dynamically at query time.
  • Pros: Unified Git workflow, CI/CD testing on metrics, and warehouse-agnostic.
  • Cons: Heavily tied to the dbt ecosystem; lacks built-in caching layers or multi-tenant app serving.
• Cube
  • Best for: Teams building embedded analytics, consumer-facing data apps, or needing an API-first headless layer.
  • How it works: Defines cubes and views in YAML or JavaScript schema files that can sit downstream of your dbt models. It exposes a powerful caching/pre-aggregation engine and multiple APIs (SQL, REST, GraphQL).
  • Pros: Exceptional performance via pre-aggregations, visualization-agnostic, and works great with diverse front-ends.
  • Cons: Operating a separate semantic codebase/service alongside your transformation layer.
• Warehouse-Native Layers (Databricks Metric Views / Snowflake Semantic Views)
  • Best for: Teams committed 100% to a single cloud data platform.
  • How it works: Defining KPIs and semantics natively inside the data lakehouse/warehouse via YAML/SQL, governed by tools like Unity Catalog.
  • Pros: Zero extra infrastructure, tight native security/governance, and optimized execution.
  • Cons: Platform lock-in; lacks portability if you query multiple clouds.
• BI-Native with Strong Code Options (Looker / Holistics / Omni)
  • Best for: Teams whose primary output is BI and who want robust, expressive semantic modeling coupled with the interface. Looker uses LookML, while newer tools like Holistics use code-first definitions.

Quick Decision Framework

1. If you already use dbt and want minimal infrastructure overhead , adopt the dbt Semantic Layer.
2. If you need to feed customer-facing apps, require advanced caching, or need multi-API access (REST/GraphQL) , go with Cube.

To help narrow this down, tell me:

• What is your primary data warehouse (Snowflake, BigQuery, Databricks, etc.)?
• Are you mostly feeding internal BI dashboards , or building external/embedded data applications?

If your goal is specifically “data models and metrics as code, version-controlled in Git, with a growing team”, I’d start with dbt Semantic Layer / MetricFlow unless you have a strong need for an independent metrics-serving API.

My shortlist

The important distinction is definition vs. serving. dbt's approach puts semantic definitions next to your transformations; Cube is more of a standalone semantic and serving layer with APIs, caching and pre-aggregation.

What I'd do for a growing team

1. Make dbt the source of truth for durable data models.

Put things like:

models/
  staging/
  intermediate/
  marts/

metrics/
  revenue
  active_customers
  retention
  pipeline

under Git/PR review. The important principle is that a metric shouldn't secretly live inside a Tableau workbook or someone's SQL notebook.

2. Use MetricFlow/dbt Semantic Layer for canonical metrics.

This is particularly attractive if you're already standardized on dbt. MetricFlow makes entities, measures, dimensions, time semantics, and metric definitions explicit rather than hiding them in dashboard SQL.

3. Add Cube only if serving becomes the problem.

I'd bring in Cube when you need the same governed metrics exposed to embedded analytics, applications, multiple BI tools, APIs, or high-concurrency workloads. That's where its caching/pre-aggregation and API-first architecture become meaningful rather than just additional infrastructure.

The architecture I'd recommend

Sources
   ↓
dbt
   ├── staging / marts
   ├── tests
   ├── lineage
   └── semantic definitions
          ↓
    MetricFlow / dbt Semantic Layer
          ↓
   ┌──────┼─────────┐
   ↓      ↓         ↓
  BI    Notebooks   AI
   │
   └── Cube (optional)
          ↓
   APIs / Embedded Analytics

That gives you a very useful separation:

dbt = “What is the data?”
Semantic layer = “What does the business metric mean?”
Cube = “How do we serve that metric efficiently everywhere?”

One caveat I'd take seriously

Don't create a semantic layer just because the team is growing. Establish metric ownership and review rules first. A tool won't resolve whether “revenue,” “active customer,” or “churn” has multiple legitimate definitions.

For a typical 5–30 person data organization, my default would be:

dbt + MetricFlow/dbt Semantic Layer + your existing BI tool. Add Cube later if you develop an API/embedded/high-performance serving requirement.

That's the lowest-complexity path to genuinely metrics-as-code without creating a second modeling system prematurely. Current 2026 comparisons similarly position dbt as the natural choice for dbt-centered teams and Cube as the stronger choice when serving metrics to applications and many consumers becomes important.

If you tell me your warehouse (Snowflake/BigQuery/Databricks/etc.), BI tool, dbt Core vs Cloud, and approximate team size, I can narrow this down to a concrete architecture and migration path.

Choosing the "best" semantic layer or metrics store depends heavily on your existing data stack and how you plan to consume those metrics (BI dashboards, AI/LLM agents, or embedded application APIs). Because your goal is managing models as code, you want a solution that lives in Git, supports CI/CD, and prevents metric drift.

The top choices for a growing data team sort neatly into distinct architectural use cases:

• dbt Semantic Layer (MetricFlow) — Best if you are already a dbt shop. Metrics are defined in version-controlled YAML files right next to your transformation models. It is vendor-neutral, heavily adopted, and plugs cleanly into modern BI tools and AI workflows.
• Cube — Best for headless, API-first, or embedded analytics. If you need to serve consistent metrics via REST, GraphQL, or SQL APIs to custom applications—or feed low-latency data to agentic AI apps—Cube's caching and developer-focused architecture excel.
• Snowflake Semantic Views or Databricks Metric Views — Best if you want a platform-native, single-vendor ecosystem. If your compute and storage live entirely inside Snowflake or Databricks, managing semantics natively in the data layer reduces integration overhead and securely grounds your internal AI tools.
• Looker (LookML) — Best for heavy enterprise governance if you are standardized on Looker. LookML remains a powerful, mature code-based modeling language, though it tightly couples your semantic definitions to the Looker ecosystem unless paired with external connectors.

To help narrow down the ideal fit, tell me:

• What is your core data warehouse or storage platform (Snowflake, BigQuery, Databricks, etc.)?
• How do your users primarily consume analytics (standard BI dashboards, custom web applications, or AI/LLM assistants)?

If your priority is “data models and metrics as code, with Git/CI/review as the operating model,” I’d shortlist dbt Semantic Layer/MetricFlow and Cube, with the choice depending on where you expect the semantic layer to live.

My recommendation

Start with dbt Semantic Layer if your team is already heavily invested in dbt. MetricFlow lets you define and maintain metric logic in code and compiles metric requests into reusable SQL. dbt's current Semantic Layer also exposes governed metrics to BI, applications, notebooks, and AI systems.

I'd choose Cube instead if you want the semantic layer to become a platform consumed by lots of things, rather than primarily an extension of your transformation workflow. Cube's models are code-first, and it provides a standalone semantic runtime with SQL, REST, GraphQL and MCP interfaces, centralized access control, and pre-aggregation/caching.

The architecture I'd aim for

Sources
   ↓
Warehouse
   ↓
dbt transformations
   ↓
Semantic models / metrics as code
   ↓
┌───────────────┬───────────────┬───────────────┐
│ BI            │ Applications  │ AI / Agents   │
│ dashboards    │ APIs          │ MCP           │
└───────────────┴───────────────┴───────────────┘

The important architectural distinction is: don't make your BI tool the source of truth for metrics. Put definitions such as revenue, active_customer, net_retention, and conversion_rate in a version-controlled semantic layer, then have downstream tools consume them. That's what prevents the classic situation where Finance, Product, and Sales each have a slightly different definition of “revenue.”

For a growing team, I'd use these decision rules

• Already all-in on dbt + primarily BI: → dbt Semantic Layer
• Need embedded/customer-facing analytics: → Cube
• Multiple BI tools + APIs + AI agents: → Cube
• Want the smallest conceptual jump from dbt models to metrics: → dbt Semantic Layer
• Want a standalone, reusable semantic service: → Cube
• Want maximum control and an open-source semantic runtime: → Cube Core is particularly interesting; it's headless and can be self-hosted.

One nuance: MetricFlow is the underlying open-source semantic/query engine; dbt Semantic Layer is the broader managed product around it. So I wouldn't evaluate “MetricFlow vs. Cube” as though they're exactly equivalent products.

My default choice for a growing modern data team: dbt + dbt Semantic Layer if analytics/BI is the main destination; dbt + Cube if you expect the semantic layer to become infrastructure for BI, applications, and AI. The latter is the more flexible long-term architecture, while the former is generally simpler to operate if you're already a dbt shop.

If your priority is “data models and metrics as code, with Git, CI, code review, and room to grow,” I’d shortlist dbt Semantic Layer / MetricFlow, Cube, and Lightdash. My default choice depends mainly on how broadly you expect the semantic layer to be consumed.

My recommendation

1. Start with dbt Semantic Layer if you're already a serious dbt shop

This is the most natural architecture if your models, tests, lineage and documentation already live in dbt. MetricFlow lets you define semantic models and metrics alongside those models, with the semantic layer generating queries dynamically.

I'd pick it when:

• dbt is already your modeling standard
• most consumption is BI/analytics
• you want the fewest additional systems
• your team values metric definitions living next to transformations

The downside is that you're making dbt's ecosystem a more central dependency.

2. Pick Cube if you expect the semantic layer to become infrastructure

This is my strongest recommendation for a growing team that wants to future-proof the architecture.

Cube Core is explicitly code-first: models, configuration and access policies can live in version control, with CI/code review and isolated environments. It also provides a serving layer above the warehouse, including SQL, REST, GraphQL and MCP interfaces, plus caching and access control.

That becomes valuable when the same metric needs to power:

warehouse → BI → dashboards → embedded analytics → internal applications → AI agents

rather than just:

warehouse → BI

In other words, I'd use dbt for durable transformation/modeling and Cube for the semantic/serving layer. That's also the architecture Cube describes for dbt teams.

3. Pick Lightdash if you want the most dbt-native OSS experience

Lightdash is particularly attractive if you want metrics defined in YAML/Git and immediately exposed through an analytics UI. Its semantic layer defines metrics, dimensions and tables as code, including definitions directly within a dbt project.

I'd choose it for a team saying:

“We want dbt + Git-managed metrics + self-service analytics, and we don't want to assemble a bunch of separate products.”

It's less compelling than Cube if your eventual goal is a semantic layer serving lots of applications and interfaces outside BI.

The architecture I'd use

For a growing team, I'd aim for:

                Git
                 │
        ┌────────▼────────┐
        │       dbt       │
        │ transformations │
        │ tests + lineage  │
        └────────┬────────┘
                 │
          warehouse models
                 │
        ┌────────▼────────┐
        │ Semantic layer  │
        │                 │
        │ entities        │
        │ dimensions      │
        │ metrics         │
        │ relationships   │
        │ access rules    │
        └───────┬─────────┘
          ┌─────┼──────┬────────┐
          ▼     ▼      ▼        ▼
         BI   Notebooks Apps    AI

The important architectural distinction is: don't put your canonical business metric definitions inside the BI tool if you expect multiple consumers. Put them in a version-controlled semantic layer upstream of those consumers.

That's increasingly important as AI enters the picture: an agent querying raw warehouse tables can produce a different definition of “revenue” from your dashboard, whereas a governed semantic layer gives all consumers the same definitions and access rules.

Bottom line

If you're already on dbt: start with dbt Semantic Layer/MetricFlow unless you have a clear need for a separate serving layer.

If you're building a strategic, company-wide metrics platform: I'd lean Cube + dbt.

If you want an open-source, dbt-native analytics experience: Lightdash is very compelling.

The key question I'd use to make the decision isn't “which semantic layer has the best metric syntax?” It's “how many different things will consume these metrics over the next 2–3 years?” Once the answer is BI + applications + AI + embedded analytics, the case for an independent serving layer like Cube gets considerably stronger.

For a growing data team focused on managing data models as code (Analytics Engineering), the dbt Semantic Layer powered by MetricFlow is the leading choice if you already use dbt for transformations, while Cube is the premier headless, tool-agnostic alternative if you serve a diverse stack of applications, multiple BI tools, and AI agents. Choosing the right solution depends heavily on your team's existing infrastructure, desired governance model, and where your data is processed.

Top Options for Data-As-Code Teams

• dbt Semantic Layer (MetricFlow) : Best for teams already standardizing transformations in dbt . Metrics are defined in version-controlled YAML files directly alongside your SQL models, ensuring a single source of truth that feeds out to BI tools via standardized APIs.
• Cube : Best as a headless, universal semantic layer. It features robust caching, pre-aggregations, and multi-protocol access (SQL, REST, GraphQL), making it ideal if you are building embedded analytics or powering AI apps outside traditional BI.
• Snowflake Semantic Views / Databricks Unity Catalog Metric Views : Best if you are entirely locked into a single modern cloud data platform and want native, high-performance semantic definitions tied directly into the warehouse's security and AI catalog.
• AtScale : Best for large enterprises requiring heavy backward-compatibility with Excel, MDX/DAX, and traditional BI systems while managing virtual autonomous aggregates.

To help narrow down the exact fit, tell me:

• What is your primary data warehouse or platform (Snowflake, Databricks, BigQuery, etc.)?
• What downstream tools do you need to feed (Tableau, Power BI, custom web apps, or AI/LLM agents)?