Semantic Layer Tools Compared: dbt Semantic Layer, Cube, AtScale, and LookML

A semantic layer is a business-friendly abstraction between your data warehouse and your BI tools. Instead of every analyst writing their own SQL to calculate revenue, churn rate, or active users — and getting different answers — the semantic layer provides a single, centralised definition of each metric that every tool queries. This guide compares the leading semantic layer tools: dbt Semantic Layer, Cube, AtScale, and LookML.

Why the semantic layer problem exists

Analytics teams without a semantic layer face the fragmentation problem at scale. The SQL analyst calculates revenue as SUM(order_amount) WHERE status = 'completed'. The Tableau developer calculates it as SUM(revenue) from a different table. The Python data scientist uses yet another calculation from a third table. Leadership reports from a fourth source. When the numbers disagree in the board meeting, everyone re-runs their calculations and finds subtle differences.

A semantic layer solves this by defining metrics once, in code, and serving those definitions to every downstream tool. Revenue is defined once. Every tool that queries "revenue" gets the same SQL, the same filters, the same result.

dbt Semantic Layer

The dbt Semantic Layer (available with dbt Cloud) adds a metrics definition layer on top of dbt models. Metrics are defined in YAML files in the dbt project alongside the model definitions:

A metric definition specifies the model it references, the measure (how to aggregate), and dimensions (which columns can be used to slice the metric). The dbt Semantic Layer exposes these metric definitions via the Semantic Layer API, which BI tools and analytics clients can query.

**What works well**: Deep integration with the dbt data transformation workflow. Metrics live in the same version-controlled repository as transformation logic, so changes are auditable and metrics stay in sync with model changes. Native support for time grains, where clauses (filters), and ratio metrics.

**What does not work yet**: Semantic Layer API coverage across BI tools is incomplete. Tableau, Power BI, and Looker can all query it, but with varying depth of integration. More complex metric types (funnels, cohort analysis, complex multi-step calculations) require workarounds. The tool is maturing rapidly — capabilities have expanded significantly in each dbt release cycle.

**Best for**: Teams already on dbt Cloud who want to centralise metrics without adopting a separate tool.

Cube

Cube (formerly Cube.js) is a headless semantic layer — it sits between any data source and any downstream consumer, defining a data schema (cubes, measures, dimensions, segments) that is translated to SQL and executed against your warehouse.

Cube's data schema is defined in JavaScript or YAML. A cube defines the base table, measures, dimensions, joins to other cubes, and pre-aggregations. The Cube API exposes a REST or GraphQL endpoint; clients query against the semantic schema rather than directly against the warehouse.

**Pre-aggregations** are Cube's most powerful performance feature. Define pre-aggregated rollup tables in the schema; Cube automatically maintains them and routes queries to the pre-aggregate when possible. For common dashboard queries against large tables, pre-aggregations reduce query time from seconds to milliseconds.

**What works well**: Polyglot — works with any SQL warehouse (Snowflake, BigQuery, Redshift, Databricks, Postgres). Embedding use case is strongest here: Cube's API is designed for embedded analytics in SaaS products, where you expose data via an API to your application rather than a BI tool. Strong JavaScript/TypeScript SDK for programmatic access.

**What does not work as well**: The JavaScript/YAML schema has a steeper learning curve than dbt's YAML-only approach. Pre-aggregation management adds operational complexity.

**Best for**: SaaS companies embedding analytics in their product; teams that need a polyglot semantic layer serving multiple data sources.

AtScale

AtScale is an enterprise semantic layer platform that focuses on compatibility with MDX-consuming tools — Excel pivot tables, Analysis Services clients, and older enterprise BI tools that use MDX rather than SQL. AtScale translates MDX queries to SQL and executes against modern cloud data warehouses.

**What works well**: MDX compatibility for organisations with heavy Excel + pivot table usage. Integration with Microsoft tools (Excel, Power BI via Analysis Services connector). Enterprise governance features (access control, lineage, certified metrics).

**What does not work as well**: More expensive than alternatives. MDX focus is less relevant for greenfield deployments not using Microsoft tools. Complex deployment and configuration.

**Best for**: Large enterprises with significant investment in Excel-based reporting and MDX tooling who are migrating to cloud warehouses but need to preserve existing tool integrations.

LookML (Looker)

LookML is Looker's semantic layer definition language. It is not a standalone tool — it is the Looker platform's internal modeling layer. LookML defines views (tables with measures and dimensions), explores (joinable sets of views), and dashboards within Looker.

LookML is the most mature semantic layer in terms of features and the largest installed base. The concepts (explores, dimensions, measures, derived tables, PDTs) are powerful and expressive. The trade-off is vendor lock-in: LookML only works with Looker. Migrating from Looker to a different BI tool means rewriting all LookML definitions.

**What works well**: Decades of refinement. The most complete semantic layer feature set. Excellent access control, derived tables, liquid templating for dynamic SQL. Looker's governed self-service model (business users explore within the guardrails of the LookML model) is the strongest among BI tools.

**What does not work as well**: Looker licensing cost. LookML is proprietary — your metric definitions only work with Looker.

**Best for**: Organisations committed to Looker as their primary BI platform who want the strongest possible governed self-service model.

Choosing between them

The choice depends primarily on your existing tooling and use case:

- **Already on dbt Cloud, want metrics without a new tool**: dbt Semantic Layer

- **Need a polyglot semantic layer serving multiple BI tools and APIs**: Cube

- **Large enterprise with heavy Excel/MDX investment**: AtScale

- **Looker is your primary BI tool**: LookML

The semantic layer market is converging on open standards (the dbt Semantic Layer's MetricFlow specification, XMLA for MDX compatibility). Vendor lock-in risk is real — invest in understanding the migration cost before committing to a proprietary semantic layer.

For the broader context on metrics governance, see what is a semantic layer and self-service analytics. Our data architecture consulting practice designs semantic layer architectures and manages BI platform migrations — book a free consultation.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.