TL;DR
A metric store is a centralised system for defining, computing, and serving business metrics — replacing the pattern where the same metric (revenue, customer count, churn) is defined differently in every BI tool, dashboard, and operational system. Metric stores expose definitions via API to any consumer, ensuring metric consistency across the organisation. The category emerged 2020–22 alongside <a href="/glossary/headless-bi" class="text-brand-600 underline decoration-brand-200 underline-offset-2 hover:text-brand-700">headless BI</a>; products in the space include dbt Semantic Layer (MetricFlow), Cube, AtScale, and LookML.
What is a metric store?
A metric store is a system that centralises the definition, computation, and serving of business metrics. Rather than letting each BI tool, dashboard, or operational system own its own definitions of revenue, MRR, customer count, churn, etc., a metric store holds the canonical definitions and exposes them via API to any consumer.
It is closely related to headless BI; the two terms are often used interchangeably. The narrower distinction is that 'metric store' emphasises the storage and computation aspect of metrics, while 'headless BI' emphasises the API-first consumption pattern. They describe largely the same architectural layer.
Why metric stores exist
Modern data stacks have many consumers of metrics: BI dashboards, embedded analytics, AI/LLM tools, reverse-ETL pipelines, customer-facing analytics, internal operational tools. Without centralisation, each consumer owns its own metric definitions — and the same metric (revenue, customer count) is calculated differently in different places.
This metric-fragmentation problem produces visible organisational pain: conflicting numbers in different reports, slow new-tool adoption (because every tool needs metric definitions ported), and trust erosion as users discover that 'revenue' means different things depending on where they look.
Metric stores solve the problem by being the single source of truth for metric definitions. Every consumer queries the metric store and gets a consistent answer.
What a metric store contains
- Metric definitions: the SQL or expressions that compute each metric, version-controlled and tested
- Dimensions: the attributes by which metrics can be sliced (customer segment, product line, geography, date)
- Joins: how dimensions and metrics relate at the data-model level
- Metadata: documentation, owners, business descriptions, calculation methodology
- Access policies: who can query which metrics under what conditions
- Caching layer: pre-computed aggregations for performance
- API: SQL, GraphQL, or REST endpoints for consumers to query
Metric-store products
| Product | Origin | Notes |
|---|---|---|
| dbt Semantic Layer (MetricFlow) | dbt Labs | Tightest dbt integration; YAML-based definitions |
| Cube | Independent (founded 2019) | Open-source core, broad consumer support |
| LookML | Google (Looker) | Dominant in legacy Looker installations |
| AtScale | Independent (founded 2013) | Enterprise focus, OLAP-style |
| Lightdash | Independent | Open-source, dbt-native |
| Transform (Aaaccquired by dbt Labs in 2023) | Origin of MetricFlow | Now part of dbt Semantic Layer |
Common pitfalls
- 1. Adopting a metric store without definition discipline. The tool only solves the consistency problem if the metric-definition team enforces single-source-of-truth discipline. Without that, the metric store becomes another place where definitions diverge.
- 2. Underestimating consumer migration. Existing dashboards built against raw warehouse tables must be migrated to query the metric store. This is typically 1–2 quarters of focused work.
- 3. Treating the metric store as 'just a SQL layer'. Metric stores are about metric semantics, not just SQL templating. The discipline of defining metrics consistently — once, with documentation and tests — is what produces the value, not the SQL itself.
Related concepts
Headless BI is largely synonymous. Metric layer is also used interchangeably. Dimensional modeling discipline still applies underneath. Data products are the broader productisation pattern that metric stores enable for metric assets.
At a glance
- Category
- Business Intelligence
- Related
- 5 terms
Frequently asked questions
Is metric store the same as headless BI?
Largely yes — the terms are used interchangeably. 'Metric store' emphasises the storage/computation aspect; 'headless BI' emphasises the API-first consumption pattern. They describe the same architectural layer in slightly different framings.
Should we adopt a metric store?
If multiple BI tools or operational systems consume the same business metrics with definitional inconsistency, yes. If you have one BI tool and few external metric consumers, the architectural investment may exceed the benefit. The bar is roughly 'three or more meaningful metric consumers' — at that point, fragmentation becomes operationally painful.
Does the metric store replace dbt?
No — they're complementary. dbt models the dimensional data; the metric store defines metrics on top of those models. dbt's own Semantic Layer (built on MetricFlow) is one option but not the only one — Cube and others integrate with dbt without requiring the dbt Semantic Layer specifically.
Sources
- dbt Labs Semantic Layer documentation
- Cube documentation
- Modern Data Stack reports (2024–25)
Fairview is an operating intelligence platform that consumes metrics from existing metric stores (Cube, dbt Semantic Layer) — using the centralised definitions teams have already built rather than recreating them in a Fairview-specific layer. Start your free trial →
Siddharth Gangal is the founder of Fairview. He built the metric-store-aware ingestion layer after watching companies invest in Cube and dbt Semantic Layer foundations only to have new operating tools recreate the same definitions in tool-specific syntax — defeating exactly the centralisation that the metric-store investment was supposed to produce.
See it in Fairview
Track Metric Store automatically.
14-day free trial. No credit card. First data source connected in 5 minutes.