Build a Metrics Layer Without Looker or dbt Semantic Layer

Three dashboards. Three definitions of revenue. The exec dashboard shows $500k because it counts recognized revenue. The sales dashboard shows $480k because it excludes partner deals. The finance dashboard shows $520k because it includes accrued but unbilled. Nobody's wrong — they're just answering different questions using the same word.

That's not a visualization problem. No amount of chart polish fixes it. It's a definition problem, and the solution is a metrics layer: a single, canonical definition of each business metric that every dashboard, query, and AI conversation draws from. One definition, one number, no more reconciliation meetings.

The concept isn't new. Looker built a company on it with LookML. dbt formalized it with MetricFlow. Both work. Both also come with tradeoffs that most teams under 50 people shouldn't have to accept.

The Looker path: powerful, expensive, locked

LookML is genuinely good at what it does. You model your entire data layer in a declarative language — dimensions, measures, joins, access filters — and every Looker dashboard, Explore, and API call resolves against those definitions. When it works, it works well. The governance is real.

The problem is the price of entry. LookML is a proprietary modeling language that requires dedicated expertise. You're hiring (or training) a LookML developer. The definitions live inside Looker's ecosystem — if you want those same metrics in a notebook, an AI agent, or a tool that isn't Looker, you're building an extraction layer on top of Looker's API. At $50-100k/year and a multi-month modeling effort, that's a reasonable investment for a 200-person analytics org. For a team of eight, it's buying a commercial kitchen to make toast.

The dbt path: open, but heavier than it looks

dbt's Semantic Layer is the open alternative, and in principle it's exactly right. MetricFlow lets you define metrics in YAML alongside your dbt models, version them in Git, and query them through a consistent API. Metrics live next to the transformations that produce them — the mental model is correct.

In practice, three things trip up smaller teams:

First, the YAML definitions are verbose. A single metric with a few dimensions, filters, and time grains can span 40+ lines of configuration. That's not a dealbreaker for a team with mature dbt practices, but it's a real barrier for a team that just wants "MRR = this calculation, everywhere."

Second, the query API requires dbt Cloud. You can define metrics in dbt Core, but actually querying them programmatically — the part that makes a semantic layer useful beyond documentation — needs a dbt Cloud subscription. The spec is open; the runtime isn't.

Third, MetricFlow only works with dbt-managed models. If some of your data lives outside dbt — a SaaS API you query directly, a Google Sheet the finance team maintains, a Postgres table that doesn't go through your transformation layer — those sources can't participate in your metric definitions. You end up with a semantic layer that covers 70% of your metrics and a spreadsheet for the rest.

None of this makes dbt's approach wrong. For mature data teams with a full dbt project and a Cloud subscription, it's the natural choice. But "mature dbt project" is doing a lot of work in that sentence. We covered the full landscape in the best semantic layer tools of 2026 — dbt is option one on that list for a reason.

What most teams actually need

Strip away the tooling debates and a metrics layer has three jobs:

1. Define each metric once — the name, the calculation, the filters, the edge cases.
2. Enforce that definition everywhere it's used — dashboards, ad-hoc queries, AI-generated SQL.
3. Detect when something upstream changes and the definition might be wrong.

Most teams under 50 don't need a proprietary modeling language or an enterprise-grade governance stack to accomplish this. They need a place to write definitions, a way to use them, and an alert when they break.

How Fastero's metrics layer works

Fastero takes the position that a metric definition should be as easy to create as a saved query and as trustworthy as a governed model. Here's the concrete workflow.

Define metrics in a UI or import from dbt. You write the definition — no proprietary language, no 40-line YAML files. A metric definition looks like this:

MRR (Monthly Recurring Revenue)
= SUM(subscriptions.amount)
  WHERE status = 'active'
  AND plan_type != 'trial'
  Granularity: monthly
  Dimensions: plan, region

That's the actual mental model: a name, a calculation, filters, and the dimensions you want to slice by. Behind the scenes Fastero stores this as structured metadata, but you never have to write or debug YAML.

If you already have dbt metric definitions, import them. Fastero reads your MetricFlow YAML and creates the corresponding definitions — you keep what you've built and extend it with governance and non-dbt-source support.

Validate against live schemas. This is where most "just write it in a wiki" approaches fall apart. Fastero validates each metric definition against the actual schema of the connected source. If subscriptions.amount doesn't exist — because someone renamed the column, because you connected a different database, because a migration dropped it — you know immediately, not three weeks later when the CFO asks why the board deck shows zero.

Schema validation is the difference between a definition and a contract. A definition says what MRR should be. A contract tells you when reality stops matching.

Use metrics across dashboards, SQL, and AI conversations. Once defined, a metric is available everywhere in Fastero. Build a dashboard widget that pulls MRR — it resolves against the definition. Run a query in the SQL editor — you can reference the metric directly. Ask the AI agent "what was MRR last quarter by region?" — it generates SQL using your definition's logic, not an improvised SUM(amount) that might or might not match what Finance expects. The whole point of the NL-to-SQL layer is that it translates English to your SQL, not generic SQL.

Govern with policies, not honor systems. Metric definitions in Fastero carry governance metadata: who can edit a definition, whether changes require approval, and an audit trail of every modification. This isn't Looker-grade row-level security — if you need that, you need Looker. But for a team where the current governance model is "whoever touches the dashboard last wins," it's the difference between chaos and a process.

The gap this fills

There's a real gap in the market between "we wrote our metrics in a Google Doc" and "we deployed Looker with two dedicated modelers." The Google Doc works until someone copies the wrong SQL, and then it's silent drift. Looker works but costs six figures and months of setup.

dbt's Semantic Layer sits in between, but it requires a mature dbt project and a Cloud subscription, and it can't cover sources outside dbt. Cube is excellent if you have an engineering team to run the infrastructure — less so if you just need the definitions to exist and be correct.

Fastero's bet is that for most teams, the right answer is: define your metrics in a tool that validates them, use them across your analytics surfaces, and get alerted when something breaks. No proprietary language, no enterprise contract, no six-month modeling project. You can read the step-by-step approach in how to define your metrics once and stop the "whose number is right?" fight.

The metrics layer isn't optional anymore — not because vendors say so, but because every AI agent you point at your data will confidently return the wrong number without one. The question is how much infrastructure you want between you and a consistent answer. For most teams, the answer is: less than the market is selling you.

Try Fastero free — define your metrics once and use them in dashboards, queries, and AI conversations. No credit card required.