The “metrics layer” market has split into four credible options that each represent a different bet about where governed metrics belong. Cube, Lightdash, dbt Semantic Layer, and Looker all claim the same surface area — single source of truth for KPIs, consistent numbers across tools, governed access — but they make very different trade-offs underneath. Choosing well in 2026 is less about features and more about correctly diagnosing your problem.

What each one is actually optimized for

Cube is an embedded analytics and API-first metrics engine. It treats the semantic layer as a programmable backend: REST, GraphQL, SQL, and MDX endpoints over a YAML-defined schema, with aggressive caching, pre-aggregations, and tenant isolation built in. The center of gravity is product engineering — teams shipping in-product analytics, white-labeled dashboards, and ML feature stores that need millisecond response times against a governed model.

Lightdash is a BI tool that reads dbt directly. Metrics and dimensions live in your existing schema.yml files; Lightdash compiles them into an exploration UI without a separate semantic definition. The optimization is for analytics-engineering teams that already standardized on dbt and want self-serve exploration without buying Looker or rebuilding dimensions in a second tool.

dbt Semantic Layer (the MetricFlow-based one, now generally available across the major BI vendors) is a query-rewriting service. You define metrics: and semantic_models: in dbt; consumer tools issue MetricFlow queries; dbt rewrites them into warehouse SQL. The bet is on dbt as the universal control plane and on heterogeneous BI tooling — Hex, Mode, Tableau, Power BI, Lightdash, and the rest — sharing one governed metric definition.

Looker is the original semantic-layer BI tool and still the most mature. LookML is more expressive than any of the above (PDTs, derived tables, persistent caches, access filters, parameterized explores). It is also the most opinionated: you commit to Looker as both the modeling language and the visualization surface. Post-Google-acquisition pricing and roadmap volatility have pushed many teams to evaluate alternatives, but the product itself remains the gold standard for governed self-serve.

When each one wins

Cube wins when latency and embedding matter more than ad-hoc exploration. If you are building a customer-facing dashboard inside a SaaS product, exposing metrics over GraphQL to a React app, or feeding governed aggregates to ML features, Cube’s pre-aggregation engine and multi-tenant access controls do work nothing else on this list does well. Teams reach for Cube when “the BI tool” is something they’re building, not buying.

Lightdash wins when you have a serious dbt practice, a small or mid-sized org, and want self-serve BI that doesn’t require a second modeling layer. Defining metrics where the transformations live keeps the analytics-engineering loop tight. The pricing and self-host story are also dramatically friendlier than Looker for teams under a few hundred seats.

dbt Semantic Layer wins when BI heterogeneity is non-negotiable. Big organizations with Tableau in finance, Hex on the data team, and Power BI in operations cannot standardize on a single visualization tool, and rebuilding metric definitions in three places is how numbers diverge. MetricFlow gives those teams one definition, queryable from each tool’s native consumer integration, with row-level governance staying in dbt and the warehouse.

Looker wins when LookML’s expressiveness is genuinely required and budget supports it: complex permissioned explores across many subject areas, deep PDT chains, sophisticated row- and column-level security, embedded analytics where Cube’s API model doesn’t fit your distribution. Mature Looker shops with a serious LookML codebase rarely come out ahead by migrating.

When each one is overkill

Cube is overkill for internal-only BI. If your end users are analysts in Hex or executives in a Looker-style dashboard, you don’t need an API-first engine, and you’ll spend the savings on schema duplication. Cube is purpose-built for embedding; if you’re not embedding, you’re paying for the wrong thing.

Lightdash is overkill for teams without a healthy dbt practice. If your transformations are SQL files in Airflow or notebooks, Lightdash has nothing to compile against, and adopting it forces a dbt migration that’s a much bigger project than choosing a BI tool.

dbt Semantic Layer is overkill for a single-BI-tool shop. The whole point is heterogeneous consumption; if 95% of your users will be in one tool, that tool’s native modeling layer (LookML, Hex’s metrics, Lightdash’s dbt-native definitions) gives you better ergonomics for less complexity.

Looker is overkill for early-stage data teams. The licensing cost, LookML learning curve, and the team you need to maintain it rarely pencil out below ~50 dashboard consumers. Most teams under that threshold are better served by Lightdash, Hex, or Metabase against a well-modeled warehouse.

How we frame the decision

Two questions sort the field cleanly. First: are you embedding analytics in a product, or serving internal BI? Embedding pushes you to Cube. Second, for internal BI: do you need one BI tool to win, or many BI tools to coexist? “One tool wins” with a serious dbt practice points to Lightdash; “one tool wins” with budget and complex governance points to Looker; “many tools must coexist” points to dbt Semantic Layer.

The wrong answer in each case is recognizable: a Cube deployment for an internal analyst team, a Looker bill for a 15-person company, a dbt Semantic Layer rollout where the only BI tool is Tableau, or a Lightdash adoption that triggers a six-month dbt migration first. The metrics-layer wars in 2026 are decided less by the tools and more by whether the team chose the one that matches the problem they actually have.