A metric store — call it a semantic layer, a metrics catalog, a headless BI layer, whichever vendor framing you prefer — is a system whose job is to be the single place where business metrics are defined, computed, and served to consumers. dbt’s Semantic Layer, Cube, MetricFlow, AtScale, Looker’s LookML; the implementations differ but the contract is the same. One definition of MRR, one of customer count, one of pipeline velocity, served identically to dashboards, notebooks, reverse-ETL, and AI agents.
The marketing pitch writes itself: stop arguing about whose number is right. The reality is more conditional. A metric store is the right answer when specific organizational signals are present and a costly mistake when they are not. Building one prematurely creates a layer your team has to maintain, debug, and version against a problem that doesn’t exist yet at your scale.
Signals that justify a metric store
You have multiple consumption surfaces and they disagree. The defining symptom is the same number — ARR, gross margin, weekly active users — appearing in three places with three values. A dashboard says one thing, a board deck a second, a Slack number from the head of finance a third. Once that pattern recurs across more than one metric, the problem is structural. No amount of “let’s all agree to use the official dashboard” will fix it, because the BI tool, the reverse-ETL job, and the analyst’s notebook are all computing the metric independently from raw tables. A metric store is what makes that impossible: the definition lives in one place, and every consumer pulls from it.
Your AI surface area is growing. This is the signal that has shifted in the last eighteen months. When AI agents and LLM-driven internal tools start asking your warehouse questions in natural language, they need a layer of definitions to ground against. Without one, every agent invocation is a fresh attempt to translate “what was Q1 revenue” into SQL, and the answers drift. A metric store gives the agent a finite, reviewed surface area: these are the metrics, these are the dimensions, this is what they mean. The cost of getting this wrong is now an agent confidently quoting a wrong number to an executive in real time.
Your metric logic is non-trivial and contested. If your definition of “customer” requires four exclusions, two attribution rules, and a side argument about how to count parent accounts versus subsidiaries, that logic should live in code, in one place, reviewed in pull requests. If it lives inline in twenty dashboard tiles, no one can change it safely. A metric store is the version-controlled home for the logic that finance, RevOps, and product all want their fingerprints on.
You’re shipping metrics to systems that bypass BI entirely. Reverse-ETL into Salesforce, customer success tools, paid-media platforms, internal applications. These consumers don’t get the benefit of a BI tool’s aggregation logic — they need the metric served to them, computed correctly, with the same definition as the dashboard. Once metrics leave the BI tool and start landing in operational systems, the BI tool can no longer be the source of truth.
You have more than one analytics team or business unit computing the same metrics. Two teams independently building the same metric in their own dbt projects is the precondition for divergence. A shared metric store is the forcing function that makes them converge.
Alternatives at smaller scale
Below those signals, a metric store is overhead. The alternatives are simpler, well-understood, and sufficient for most companies under roughly $50–100M in revenue with a single analytics team.
dbt models with strict review. A well-organized dbt project with a clean three-tier structure — sources, metrics, marts — gets you most of the benefit. Metric logic lives in versioned SQL, the marts layer is what dashboards consume, and a pull request review process keeps definitions from forking. This is not as good as a true metric store, because dimensional flexibility is limited and BI tools can still recompute things downstream, but it costs nothing extra to maintain and is what most data teams already have.
One BI tool, one definition. If you have a single BI tool — Looker, Power BI, Tableau, Mode — and you can enforce that all metrics flow through it, you get a de facto semantic layer for free. LookML, in particular, is a metric store that happens to ship inside Looker. The constraint is that everything has to go through the BI tool: notebooks, AI agents, and reverse-ETL all break the model.
A single-team discipline. With fewer than five analysts, the cheapest semantic layer is a Slack channel and a habit of asking “is this the official definition” before shipping a number. It does not scale, but it works for years longer than people expect, and it has zero technology cost.
How to know you’ve crossed the line
You’ve crossed into metric store territory when (a) the cost of a wrong metric making it to a customer-facing surface is real money or real reputational damage, (b) your team is spending material time reconciling numbers between systems instead of producing new analysis, or (c) you’re about to expose your warehouse to an AI agent and you cannot tell it, in one place, what your metrics are. The first two are obvious in retrospect. The third is the one most teams underestimate today, and the one that has shifted the calculus most sharply this year.
Build the store when the signals are present. Skip it when they are not. The wrong move is to install one because a vendor told you it was best practice, then watch your team maintain a layer no one is consuming correctly.