Abstract

The semantic layer - the translation between business concepts like “monthly active users” or “net revenue” and the SQL expressions that compute them - has historically been locked inside individual BI tools. Looker’s LookML, Tableau’s calculated fields, and Power BI’s DAX measures express similar business logic in incompatible languages, forcing organizations to maintain parallel definitions that drift out of sync. The move toward a vendor-neutral semantic layer, embodied in MetricFlow (now part of dbt), Cube’s semantic layer API, and emerging integrations with Arrow Flight SQL, represents an architectural shift with concrete adoption patterns by early 2026. This post examines the standardization landscape, the remaining gaps, and what the practical migration path looks like for teams currently embedded in proprietary BI semantic layers.

MetricFlow and the dbt Semantic Layer

MetricFlow, donated to dbt Labs in 2023 and integrated into dbt Core in late 2023, defines metrics as first-class objects in the dbt project alongside models. A metric definition references a measure (an aggregation over a model column) and one or more dimensions (columns by which the metric can be sliced), with support for time-grain specifications and cumulative metrics. The dbt Semantic Layer exposes these definitions through a gRPC API that BI tools can query without writing SQL directly - the tool sends a metric request with dimension and time filters, and the semantic layer generates and executes the SQL. dbt Cloud’s integration with Tableau, Hex, and Mode as of early 2026 covers the most common consumption patterns; the Looker Studio connector is less mature. The key limitation is that MetricFlow defines metrics over dbt models, which means the semantic layer is downstream of the transformation layer rather than a separate concern - organizations with transformation logic outside dbt must bridge both.

Cube’s Headless BI Approach

Cube takes a different architectural stance: the semantic layer is the API, not a feature of a transformation tool. Cube’s data model is defined in YAML or JavaScript, compiled to SQL at query time, and exposed through REST, GraphQL, and SQL API endpoints. BI tools connect to Cube’s SQL endpoint as though it were a database, receiving query results that conform to the semantic model without needing native Cube connectors. This makes Cube more portable across BI tools but adds an operational dependency: Cube is a query proxy that must be kept running and tuned independently. Its pre-aggregation feature, which materializes commonly queried metric combinations into summary tables, provides a performance lever that purely passthrough semantic layers lack.

Interoperability and the Open Metrics Standard

The absence of a common format for metric definitions means that migrating from one semantic layer to another requires rewriting business logic. The ONNX for metrics problem - a serialization format that different tools can import and export - remains unsolved as of early 2026, though the dbt Semantic Layer’s public gRPC API specification provides a de facto interface that third-party tools are beginning to implement against. The Semantic Layer Alliance, formed in 2024 by a coalition of BI and data tooling vendors, has produced a draft specification for a common metric manifest format, but ratification and implementation timelines remain unclear. In the interim, the most portable pattern is defining all metric logic in a version-controlled, engine-agnostic format (MetricFlow YAML or Cube YAML) and generating both the target BI tool’s native format and SQL expressions from that source of truth.

Migration Practical Realities

Teams migrating from LookML or DAX to a vendor-neutral semantic layer face a dual-track transition: the semantic definitions must be ported, and the BI tool’s query interface must be reconfigured. Neither is straightforward. LookML’s explores, with their join graph and field visibility rules, encode relational logic that MetricFlow’s flatter metric-and-dimension model does not directly represent. DAX’s context-transition semantics and time intelligence functions have no direct equivalent in SQL-generating semantic layers. The migration path that minimizes disruption is additive: stand up the new semantic layer alongside the existing one, migrate metrics incrementally, and retire the BI tool’s native semantic layer model only after consumption patterns are validated against both.