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 specifically “data models as code” for a growing data team, I’d narrow the field to dbt Semantic Layer/MetricFlow, Cube, and AtScale. The right choice depends heavily on whether you want the semantic layer primarily to define metrics or also to serve them as an application/API layer.

My practical shortlist

| dbt Semantic Layer / MetricFlow | Cube | AtScale --- | --- | --- | --- Code-first modeling | Excellent | Excellent | Good Natural fit with dbt | Excellent | Excellent | Good Git/PR workflow | Excellent | Excellent | Good Metrics + dimensions + joins | Yes | Yes | Yes API / programmatic serving | Good | Excellent | Good Caching / pre-aggregations | More limited | Strong | Strong Embedded analytics | Not its primary focus | Strong | Strong BI-tool independence | Good | Strong | Strong Enterprise OLAP | Moderate | Strong | Strong Complexity for a small team | Lowest | Medium | Highest

What I'd choose

If you're already standardized on dbt: start with dbt Semantic Layer/MetricFlow. It keeps semantic definitions alongside your transformation models, so your workflow can essentially be:

raw → dbt models → metrics/semantic definitions → BI

That is a very clean “analytics as code” architecture. Current comparisons describe MetricFlow as the layer that defines entities, dimensions and measures on top of dbt models.

If you expect the semantic layer to become infrastructure used by lots of consumers: I'd seriously evaluate Cube. Its architecture is more explicitly a serving layer: the same governed model can expose metrics through SQL, REST, GraphQL and MCP, while providing caching/pre-aggregations and access controls.

A particularly attractive architecture for a growing engineering-heavy team is:

dbt owns durable data transformations; Cube owns the reusable semantic/serving model. Cube explicitly supports reading dbt models rather than replacing dbt, which gives you a separation between building trustworthy datasets and defining/serving business semantics.

AtScale becomes more interesting if you're heading toward a large enterprise BI/OLAP environment, especially where Excel/Power BI-style consumption and governed multidimensional models are central. Its current documentation supports programmatic data-model creation and deployment.

The architectural distinction I'd make

Don't ask only “which metrics store?” Ask what you want the layer to own.

For example:

Warehouse
   │
   ▼
dbt
 ├── staging models
 ├── marts
 ├── tests
 └── lineage
   │
   ▼
Semantic layer
 ├── entities
 ├── dimensions
 ├── metrics
 ├── joins
 ├── permissions
 └── metric contracts
   │
   ├── BI
   ├── notebooks
   ├── applications
   └── AI agents

That's important because a metrics layer primarily standardizes measures like revenue, active_users, and gross_margin; a broader semantic layer also captures entities, relationships, dimensions, join paths and access rules.

For a growing team, I'd optimize for these five things

1. Everything important is Git-versioned. Metric changes should go through PRs, reviews and CI rather than being edited only in a GUI.
2. The semantic definitions don't duplicate transformation logic. Your warehouse/dbt layer should establish the trustworthy grain and business entities; the semantic layer shouldn't become a second transformation framework.
3. Metrics have explicit ownership and tests. net_revenue shouldn't merely have SQL—it should have an owner, description, grain, dimensions, tests and a clear definition.
4. Consumers aren't coupled to one BI tool. This becomes increasingly valuable as teams add spreadsheets, notebooks, embedded analytics and AI.
5. You can evolve without rewriting everything. A five-person data team can tolerate some manual conventions. A 30-person team usually needs stronger contracts, CI/CD, governance and discoverability.

My recommendation for your situation

If I were designing this today for a growing data team, I'd evaluate these two architectures first:

Option A — simplest

dbt + dbt Semantic Layer + existing BI Best when your primary problem is metric consistency and you already have a strongly dbt-centric workflow.

Option B — more extensible

dbt + Cube + BI / APIs / applications / AI Best when you expect the semantic layer to become a piece of shared data infrastructure rather than merely a place to store metric definitions.

I would not start with a heavyweight enterprise semantic platform simply because you're growing. Start with the smallest layer that gives you version-controlled definitions, testing and consistent consumption; add serving/caching/multitenancy capabilities when your use cases actually require them.

One useful pilot is to implement just three metrics—a simple count, a revenue metric with exclusions, and a metric requiring row-level/tenant permissions—and test each candidate against real BI queries and an ad-hoc consumer. That exposes modeling and governance problems much faster than a feature checklist.

If you tell me your warehouse (Snowflake/BigQuery/Databricks/etc.), BI tool, whether you're already on dbt, and approximate data-team size, I can narrow this to a concrete architecture and migration plan.

For example:

Warehouse
   │
   ▼
dbt
 ├── staging models
 ├── marts
 ├── tests
 └── lineage
   │
   ▼
Semantic layer
 ├── entities
 ├── dimensions
 ├── metrics
 ├── joins
 ├── permissions
 └── metric contracts
   │
   ├── BI
   ├── notebooks
   ├── applications
   └── AI agents

That's important because a metrics layer primarily standardizes measures like revenue, active_users, and gross_margin; a broader semantic layer also captures entities, relationships, dimensions, join paths and access rules.

For a growing team, I'd optimize for these five things

Managing data models as code (Analytics as Code) for a growing team points you directly toward decoupled, Git-versioned semantic layers. The "best" choice depends heavily on whether your team is already standardized around dbt or looking for a universal, high-performance API/cache layer.

The top tools fit distinct scaling needs:

• dbt Semantic Layer (MetricFlow) : Best if your team is already fully bought into the dbt ecosystem. Metrics are defined in YAML right alongside your transformation models, giving you native Git workflows, CI/CD testing, and line-of-sight lineage. It compiles definitions down to optimized SQL queries for your data warehouse.
• Cube : Best for a decoupled, multi-warehouse stack, embedded analytics, or heavy application/AI agent integration. Cube uses code-defined data models (JavaScript/TypeScript or YAML schemas) and adds a powerful caching/pre-aggregation engine. It exposes your metrics not just to BI tools, but via REST, GraphQL, SQL, and Model Context Protocol (MCP) for AI workloads.
• Warehouse-Native Options (Snowflake Semantic Views / Databricks Metric Views) : Best if you are entirely locked into a single modern cloud data platform and want zero-latency management. They are convenient for in-platform AI/SQL features, but less flexible if you switch or multi-home your infrastructure.

To help narrow down the exact fit, tell me:

• Are you already using dbt for transformations?
• Are you serving metrics strictly to BI dashboards , or also to customer-facing apps / AI agents?
• Which data warehouse are you built on?

If your goal is specifically “data models as code” for a growing data team, I’d narrow the field to dbt Semantic Layer/MetricFlow and Cube, with Lightdash as a strong option if BI is the main consumer.

My recommendation

Start with dbt Semantic Layer if your team already uses dbt heavily. It gives you the cleanest workflow:

raw data → dbt models → semantic models/metrics → BI / notebooks / AI Metric definitions can live in version-controlled YAML alongside the transformation code, with Git review, tests, lineage, and documentation.

That makes it particularly attractive for a growing team where the bigger problem is preventing metric definitions from fragmenting across dashboards and analysts.

When I'd choose Cube instead

Choose Cube if you expect the semantic layer to become an actual data product/API consumed by multiple things:

• internal BI
• customer-facing embedded analytics
• applications
• AI agents
• multiple BI tools
• multi-tenant or fine-grained access control

Cube is more explicitly designed as a serving layer: its open-source Cube Core models metrics, dimensions, joins and access rules, while the platform adds APIs, caching/pre-aggregations, embedded analytics and agent interfaces.

A useful rule is the “second consumer” test: if metrics only go to one BI tool, dbt's semantic layer may be enough. Once the same definitions need to serve a second fundamentally different consumer, a dedicated serving layer becomes much more compelling.

How I'd compare them

| dbt Semantic Layer | Cube | Lightdash --- | --- | --- | --- Models as code | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ Git/PR workflow | Excellent | Excellent | Excellent dbt integration | Native | Very good | Native Metric governance | Excellent | Excellent | Good API / application serving | Good | Excellent | Limited Embedded analytics | Good | Excellent | Limited Caching/pre-aggregation | Good | Excellent | More BI-oriented Open source | dbt Core is OSS; SL is primarily a dbt product | Cube Core is OSS | Yes Best for | dbt-centric analytics teams | Multi-consumer data platforms | dbt + open-source BI

What I'd do for a growing team

I would not start by putting every piece of business logic into the semantic layer.

Keep the responsibilities clean:

dbt

• staging and cleaning
• dimensional/fact modeling
• business transformations
• tests
• lineage
• slowly changing dimensions, snapshots, etc.

Semantic layer

• revenue
• ARR
• active_customer
• conversion_rate
• dimensions and entities
• allowed relationships/join paths
• metric-level governance

BI

• dashboards
• exploration
• visualization

That separation prevents your semantic layer from becoming another giant transformation framework.

The decision I'd make

If you told me “We're a 5–20 person data/analytics team, already using dbt, and our primary need is getting everyone to agree on metrics”, I'd pick dbt Semantic Layer.

If you told me “We're building a data platform where the same governed metrics will eventually power BI + product analytics + customer-facing dashboards + AI”, I'd pick Cube.

And if you said “We want the simplest open-source experience for analysts on top of dbt”, I'd look very seriously at Lightdash.

One important architectural point: I wouldn't think of this as dbt vs. Cube. A very strong architecture is dbt for transformation/modeling + Cube for semantic serving. Cube explicitly supports reading dbt models, so the two can occupy different layers rather than duplicating each other.

If you tell me your warehouse (Snowflake/BigQuery/Databricks/etc.), BI tool, dbt usage, and whether you need embedded analytics, I can give you a much more concrete recommendation—including what I'd put in Git and what the repository structure should look like.

If you told me “We're building a data platform where the same governed metrics will eventually power BI + product analytics + customer-facing dashboards + AI”, I'd pick Cube.

And if you said “We want the simplest open-source experience for analysts on top of dbt”, I'd look very seriously at Lightdash.

Managing your data models and metrics as code (often called Metrics-as-Code or Analytics-as-Code) for a growing data team comes down to choosing a tool that fits your existing stack, developer workflow, and how you plan to consume those metrics downstream (BI, APIs, or AI agents).

The industry landscape centers around two clear frontrunners for a code-first approach, supplemented by cloud platform natives.

• dbt Semantic Layer (Powered by MetricFlow)
  • Best for: Teams already heavily invested in dbt Core or dbt Cloud for transformations.
  • How it works: You define dimensions, entities, and metrics directly in YAML files right alongside your SQL transformation models.
  • Pros: Keeps your lineage graph unified; version control natively via Git; writes consistent queries regardless of the downstream BI tool.
  • Cons: Requires a dbt Cloud subscription for the hosted serving layer/APIs; tightly coupled to the dbt ecosystem.
• Cube
  • Best for: Growing teams needing a headless, API-first semantic layer that can feed BI tools, custom web apps, and AI agents simultaneously.
  • How it works: Uses its own data modeling language (or can read dbt semantic definitions/manifests via cube_dbt ) to define access control, pre-aggregations, and metrics.
  • Pros: Incredible performance caching layer (pre-aggregations); robust open-source core (Cube Core); completely decoupled from any single transformation tool or BI vendor.
  • Cons: Introduces a separate service/infrastructure component to manage if you don't use Cube Cloud.
• Data Warehouse Natives (Databricks Metric Views / Snowflake Semantic Views)
  • Best for: Teams looking to minimize moving parts by locking into the governance layer of their primary cloud data platform.
  • How it works: Defining semantics, metric views, and security contexts natively inside Unity Catalog or Snowflake.
  • Pros: Great for AI/Genie/Cortex integrations; less data movement.
  • Cons: Still maturing compared to dbt or Cube in terms of pure Git-based developer experience across diverse tools.

How to choose:

• If your team lives and breathes dbt , start with the dbt Semantic Layer to keep everything in one Git workflow.
• If you are building embedded analytics , need sub-second caching, or want an API-first headless setup separate from dbt, go with Cube (which can still sit on top of your dbt models).

To help narrow this down, tell me:

• What data warehouse are you using (Snowflake, BigQuery, Databricks, etc.)?
• Are you already using dbt for transformations?
• Will these metrics primarily feed BI dashboards, external APIs/apps , or AI/LLM use cases?

Managing data models as code for a growing data team means you need a solution that supports version control (Git), CI/CD, modular definitions, and seamless integration with your modern data stack (warehouse + BI + AI agents).

The industry has largely converged on a few standout tools for code-first semantic layers and metrics stores. The "best" choice depends heavily on your stack and your primary consumption use case (BI dashboards vs. low-latency embedded apps vs. AI/LLM context).

Top Contenders for Data-As-Code Semantic Layers

1. The dbt Semantic Layer (Best if you already use dbt)

If your team already uses dbt for transformations, staying within the ecosystem via the dbt Semantic Layer is the most natural path to true data-as-code metrics.

• How it works: You define metrics, dimensions, and entities alongside your staging and marts models using YAML files. It uses dbt_project structure and Git for version control.
• Pros: Single source of truth; no need to re-engineer logic outside your existing dbt workflow; natively integrates with BI tools like Sigma , Power BI, and Looker via APIs or native connectors.
• Cons: Historically tied closely to the dbt Cloud ecosystem/scheduler, and query-time performance relies entirely on your underlying data warehouse (Snowflake, BigQuery, Databricks).

2. Cube (Best for high-performance, APIs, and AI/Embedded apps)

Cube is an enterprise-grade, headless semantic layer built specifically as a universal metrics store.

• How it works: Models are defined using JavaScript/TypeScript or YAML files, fully trackable in Git. Cube acts as an independent caching server/API layer sitting on top of your data warehouse.
• Pros: Incredible performance thanks to its pre-aggregations and caching engine (great for sub-second user-facing embedded analytics). Features robust REST/GraphQL/SQL APIs, and has heavily invested in Model Context Protocol (MCP) integrations for AI agents. Can read dbt models directly.
• Cons: Introduces a separate infrastructure component to deploy and manage (unless using Cube Cloud), and requires learning Cube's modeling syntax.

3. MetricFlow / Lightweight Open Source Alternatives

• MetricFlow is the underlying query engine for dbt's semantic layer, decoupled into an open-source framework, though managing it outside dbt Cloud can be heavy.
• Other tools like AtScale cater heavily to enterprise OLAP/semantic needs with deep BI and cloud data platform integrations, while lightweight options like Spoof/SQL-based frameworks exist for smaller setups.

How to Choose for a Growing Team

• Go with the dbt Semantic Layer if your transformations are 100% in dbt, your stack is centered around a powerful cloud warehouse (like Snowflake or BigQuery), and your primary consumers are internal analysts using BI tools.
• Go with Cube if you are building customer-facing/embedded analytics requiring sub-second latencies, need a decoupled caching/API layer, or are heavily building context layers for AI agents and custom microservices.

To help narrow this down:

• What is your core data warehouse (Snowflake, BigQuery, Databricks, Postgres)?
• Are you already using dbt for data transformations?
• Are your metrics primarily for internal BI dashboards or external/user-facing applications?

If your goal is “data models as code” rather than just a centralized dashboard metric catalog, I’d narrow the field to dbt Semantic Layer / MetricFlow and Cube. AtScale is worth considering for a more enterprise/OLAP-heavy environment.

My short answer

For a growing data team already centered on dbt: start with dbt Semantic Layer (MetricFlow). For a team that wants a more general-purpose, headless semantic layer serving BI + applications + AI: choose Cube.

| dbt Semantic Layer / MetricFlow | Cube | AtScale --- | --- | --- | --- Model-as-code | Excellent | Excellent | Good dbt integration | Best | Very good | Good Metrics / dimensions | Excellent | Excellent | Excellent Complex semantic joins | Excellent | Excellent | Excellent BI consumption | Excellent | Excellent | Excellent Embedded analytics / APIs | Good | Excellent | Good AI/agent consumption | Good | Excellent | Good Caching / pre-aggregation | More warehouse-dependent | Strong | Strong Open-source foundation | MetricFlow | Cube Core | No Best fit | dbt-centric data teams | Broader analytics platform | Large enterprise

dbt's current Semantic Layer defines semantic models and metrics as version-controlled YAML and uses MetricFlow to compile metric requests into SQL.

Cube is particularly compelling if you want the semantic model to become a platform interface rather than merely a dbt feature: its models define entities, metrics, dimensions, joins and access rules, and can be exposed through SQL, REST, GraphQL and MCP.

What I'd do for a growing team

I'd structure the stack roughly like this:

Raw data → dbt transformations → semantic layer → BI / notebooks / applications / AI

The important architectural decision is to keep transformation logic and semantic logic separate:

• dbt: “What is the trustworthy orders or customer dataset?”
• Semantic layer: “What does revenue, retention, active_customer, etc. mean?”
• BI/AI/apps: consume those definitions rather than recreating them.

That separation becomes increasingly valuable as the team grows because otherwise metric definitions start leaking into Looker/Tableau dashboards, SQL notebooks, Python, spreadsheets, and eventually AI prompts.

My recommendation

Pick dbt Semantic Layer if:

• You're already heavily invested in dbt.
• Most consumption is analytics/BI.
• You want the lowest architectural complexity.
• Your semantic definitions naturally belong alongside your dbt models.
• You don't need a sophisticated standalone serving layer yet.

Pick Cube if:

• You expect the semantic layer to serve many different consumers.
• You want APIs/embedded analytics in addition to BI.
• AI agents are an important future consumer.
• You care about centralized access control and query performance.
• You want the semantic model to be a first-class platform independent of any particular BI tool.

Cube explicitly supports code-managed models and version control, including YAML/JavaScript modeling, while its caching layer uses pre-aggregations for performance.

Pick AtScale if:

• You're a larger enterprise with sophisticated dimensional/OLAP requirements.
• Lots of different BI tools need to consume the same semantic model.
• Enterprise governance and scale outweigh developer simplicity.

AtScale's current documentation specifically supports programmatic data-model creation and deployment, so it can fit a model-as-code workflow, but I'd generally evaluate it later unless you already have an enterprise-scale use case.

One important distinction

I wouldn't make the decision based on “Which metrics store is best?”

I'd ask:

“Where should our organization's canonical analytical model live, and how should every consumer access it?” That leads to a more durable architecture. Your canonical model should contain things like:

metrics:
  revenue:
    type: sum
    expression: net_amount
    entity: order

  active_customers:
    type: count_distinct
    expression: customer_id
    filter: status = 'active'

dimensions:
  customer:
    - segment
    - country
    - signup_month

relationships:
  order:
    - customer
    - product

Then Git becomes the control plane: PR → review → tests → deploy → every downstream consumer gets the same definitions.

For your stated goal, my default choice would therefore be:

dbt Semantic Layer if you're dbt-first; Cube if you're building a broader data/analytics platform.

If you tell me your warehouse (Snowflake/BigQuery/Databricks/etc.), BI tool, dbt usage, and team size, I can give you a much more concrete recommendation—including what I'd choose between dbt Semantic Layer, Cube, LookML, AtScale, and a warehouse-native approach for your specific stack.

The dbt Semantic Layer (powered by MetricFlow) is the best choice for a growing data team focused on analytics-as-code, especially if you already use dbt for transformations.

Managing data models as code (often called Analytics Engineering) requires version control, CI/CD testing, and metrics living right alongside your data transformations.

Top Semantic Layer & Metrics Store Options

Why the dbt Semantic Layer Fits Code-First Teams

• Version Control: Define dimensions and metrics in YAML files tracked in Git.
• DRY Principles: Write your business logic once in code to prevent metric drift across BI tools, AI agents, and APIs.
• Integrated Lineage: Automatically inherits data lineage from your underlying dbt models.

To help narrow down the right fit, tell me:

• What is your primary data warehouse (Snowflake, BigQuery, Databricks, Postgres)?
• What BI tools or applications do your stakeholders use to query the data?

I can give you a tailored implementation approach.

If your goal is “manage data models as code”—meaning metric definitions, joins, dimensions, and business logic should live in Git, go through PR review, have tests, and be reusable—the best choice depends on where you want that semantic contract to live and who consumes it.

A useful way to frame it:

• dbt = transformation layer (tables/models)
• Semantic layer = governed business meaning (metrics, dimensions, entities)
• Metrics store = serving those definitions consistently to BI, apps, and AI

Most growing data teams should avoid putting core metrics only inside a BI tool. The question is whether you want a dbt-native semantic layer or a dedicated metrics serving layer.

My shortlist

cube.dev Bruin## Recommendation by team stage

Early growth team (5–15 data people)

Use:

dbt + dbt Semantic Layer

A typical pattern:

Warehouse
    ↓
dbt models (SQL + tests + lineage)
    ↓
Semantic metrics (YAML)
    ↓
BI tools / analysts

This keeps ownership simple:

• engineers review SQL changes
• analysts consume trusted metrics
• definitions live in Git
• lineage remains connected

This is usually the lowest-friction path if dbt is already your modeling backbone.

---

Scaling team (15–50+ data people)

Consider:

dbt + dedicated semantic serving layer (often Cube)

Pattern:

Warehouse
    ↓
dbt models
    ↓
Semantic layer
    ↓
 ┌───────────────┐
 │ BI dashboards │
 │ Product apps  │
 │ APIs          │
 │ AI agents     │
 └───────────────┘

This becomes attractive when the same metric needs to power:

• internal dashboards
• customer-facing analytics
• APIs
• operational tools
• AI assistants

Cube’s design is aimed at serving governed metrics across multiple interfaces rather than only BI exploration.

---

What I would avoid

Putting metrics only in dashboards

Example:

Revenue = SUM(orders.amount) - refunds

defined separately in:

• Tableau
• Looker
• Power BI
• notebooks
• product code

This almost always creates metric drift.

Rebuilding your warehouse models inside the semantic layer

Your semantic layer should not become your second dbt.

A clean split is:

dbt owns:

• cleaning data
• joins that create durable models
• business transformations
• tests

Semantic layer owns:

• reusable metrics
• dimensions
• access rules
• metric definitions
• serving logic

---

The questions I would use to choose

1. Are all consumers internal BI users?

• Yes → dbt Semantic Layer or Lightdash is probably enough.

2. Will metrics power customer-facing features?

• Yes → strongly consider Cube or another serving-oriented semantic layer.

3. Do you expect AI agents to query company metrics?

• Yes → invest early in a governed semantic layer with APIs.

4. Is dbt already your source of truth?

• Yes → avoid creating a second modeling language unless you have a clear reason.

---

For a growing team starting today, my default architecture would be:

Warehouse → dbt → semantic layer → every consumer

Start with dbt Semantic Layer if your needs are mostly analytics. Add Cube (or similar) when metrics become an application/API contract rather than just a BI definition.

If you share your stack (Snowflake/BigQuery/Databricks, BI tool, team size, and whether you have embedded analytics), I can narrow this to a specific recommendation.

For a growing data team focused on managing data models as code (version-controlled, CI/CD-friendly, and decoupled from single BI tools), the "best" choice depends heavily on your existing data stack.

The top industry contenders for data-as-code semantic layers break down by use case:

• dbt Semantic Layer: Best if your team already lives and breathes dbt . It defines metrics in YAML right alongside your transformation models, supports Git workflows natively, and integrates with a wide and growing array of BI tools and AI agents.
• Cube: Best for headless/embedded analytics or application backends. Cube treats data modeling strictly as code (JavaScript/TypeScript or YAML), features a powerful caching/pre-aggregation engine, and provides robust REST/GraphQL/SQL APIs to serve metrics anywhere.
• Lightdash: Best for open-source, dbt-native BI . It lets you define metrics in dbt .yml files and gives your business users a lightweight, code-synced UI to build charts without writing SQL.
• Looker (LookML): Best if you are entirely Google Cloud / Looker standard. LookML is the gold standard for robust data-as-code semantic modeling, though it locks your semantic definitions into Looker's ecosystem unless paired with a reverse-engineering adapter.
• Warehouse-Native (Snowflake Semantic Views / Databricks Metric Views): Great for single-platform governance, but less flexible if you need a truly decoupled, multi-warehouse data-as-code approach.

To help narrow down the ideal fit, tell me:

• What is your core data warehouse (Snowflake, BigQuery, Databricks, DuckDB)?
• Are you heavily committed to dbt already?
• Do you need this semantic layer to power BI dashboards, customer-facing embedded apps , or AI/Text-to-SQL workflows?

If your goal is “manage data models as code” and you’re building a growing data team, I’d generally avoid starting with a BI-tool-native semantic layer unless you are already committed to that BI ecosystem. The strongest pattern for many modern teams is:

Warehouse + dbt for transformation/modeling → semantic layer for governed metrics → BI/apps/AI consumers.

The “best” choice depends mostly on where you want your source of truth to live and how many consumers you expect.

My shortlist

cube.dev cube.dev## My default recommendation for a growing data team

If you are already using dbt:

Start with dbt models + dbt Semantic Layer.

A typical architecture:

Sources
   ↓
Warehouse (Snowflake / BigQuery / Redshift / Databricks)
   ↓
dbt models
   ↓
Semantic metrics layer
   ↓
BI / Notebooks / Reverse ETL / AI agents

Benefits:

• Metric definitions are code-reviewed in Git.
• Changes go through pull requests.
• Definitions live close to the transformations they depend on.
• Analysts and engineers share one vocabulary.

For example:

metrics:
  - name: monthly_recurring_revenue
    type: simple
    label: MRR
    type_params:
      measure:
        name: recurring_revenue

The important cultural win is not the syntax—it’s that “revenue” becomes a governed object rather than a SQL snippet copied into 20 dashboards.

When I would choose Cube instead

I’d lean toward Cube if you expect your metrics to become a product capability, not just an analytics asset.

Examples:

• Customer-facing analytics dashboards
• Embedded reporting
• APIs serving metrics
• AI agents querying business data
• Multiple BI tools needing the same metrics

Cube’s architecture is designed around serving metrics through multiple interfaces and handling things like caching and application-facing workloads.

A common pattern is:

dbt = trusted data models
Cube = metrics serving layer

When I would choose LookML

Pick LookML if:

• Your company is already committed to Looker.
• Business users live primarily in Looker.
• You value BI governance over portability.

I would be cautious about making LookML your enterprise-wide metric source if you also expect metrics to power applications, APIs, or non-Looker consumers.

What I would avoid

Avoid putting business logic only in dashboards

You eventually get:

• Dashboard A: “active users”
• Dashboard B: “active customers”
• Product analytics: another definition

…and nobody knows which is correct.

Avoid building a semantic layer before agreeing on ownership

The hardest part is usually not tooling. It is deciding:

• Who owns metric definitions?
• What qualifies as a certified metric?
• How are breaking changes handled?
• Who approves changes?

A practical decision tree

• Mostly internal analytics + already on dbt → dbt Semantic Layer
• Need open-source BI on top of dbt → Lightdash
• Need embedded analytics / APIs / AI consumers → Cube
• Already standardized on Looker → LookML
• Enterprise Excel/Power BI-heavy environment → consider an enterprise semantic model layer such as AtScale

StackFYI BruinFor a typical growing data team starting today, I would choose dbt as the modeling-as-code foundation, then add dbt Semantic Layer first and move toward a dedicated serving layer like Cube only when you have real multi-consumer needs. That keeps the architecture simple while preserving a path to scale.

A few details would change the recommendation:

1. What warehouse are you on (Snowflake, BigQuery, Databricks, Redshift, etc.)?
2. Are your main consumers analysts/dashboards, or do you need embedded analytics/API access?
3. Are you already using dbt?