Metrics & semantic layer
Define your metrics once. Get told when they drift.
The single place your team — and your AI — agree on what “revenue,” “active user,” and “churn” actually mean. Not a six-month governance program. The lightweight version that keeps itself honest.
The problem
The SQL is easy. The meaning is hard.
Your AI can write a query in a second. What it cannot do is know that when your VP says “revenue,” she means recognized revenue — not booked, not billed, not the pipeline number Sales quotes. So it guesses. And a guessed definition does not crash; it computes a confident, plausible, wrong answer. Meanwhile the same word means three different things to three teams, and the board meeting becomes a debate about arithmetic. A metrics layer is the referee.
Define once
One definition, every surface
Write each metric a single time. Dashboards, saved queries, and AI answers all resolve to the same logic, so Sales, Finance, and CS stop reporting three different ARRs.
Ask in English
Natural language, bound to your logic
The value is not English-to-SQL — that is commoditized. It is English-to-your-SQL: questions answered with the definition you agreed on, with the query shown for verification.
Catch drift
The layer tells you when it rots
Definitions go stale the moment an upstream field is renamed or a metric is recalculated. Event-driven triggers and schema-drift detection turn silent errors into alerts.
How it works
From scattered definitions to one source of truth.
No LookML project to staff. Connect a warehouse, write your key definitions, and let your team ask against them — while Fastero watches for the upstream changes that quietly break metrics.
Connect your warehouse
Add a read-only connection to BigQuery, Snowflake, Postgres, or seven other sources. Fastero reads the schema so definitions can point at real tables and columns.
Define the metrics that cause fights
Start with the 15–25 metrics people actually argue about — revenue, ARR, active users, churn, NRR. Each gets a name, aliases, exact logic, edge cases, and an owner.
Ask questions against the definitions
Your team asks “What was NRR last quarter by region?” and the AI answers using your defined logic — not an improvised join. The generated SQL is shown so a human can verify.
Get alerted when a definition drifts
Fastero watches the schemas and pipelines your definitions depend on. When an upstream field or table changes, you get a Slack or email alert — before the number shows up wrong in a board meeting.
Want the tool-agnostic build steps? Read our guide to defining metrics once.
Honest comparison
Where Fastero fits next to dbt and Looker.
We are not the deepest governance tool, and we will not pretend to be. dbt is ideal if you already live in it; Looker is the gold standard if you can staff it. Fastero is for teams who want the outcome — one definition, plain-English answers, drift alerts — without the project.
| Capability | Fastero | dbt Semantic Layer | Looker |
|---|---|---|---|
| Where metrics live | Lightweight definitions on your connected warehouse | YAML in your dbt project (MetricFlow) | LookML modeling layer |
| Query in natural language | Built in — answers against your definitions | Via connected BI tools / API | Looker + partner LLM add-ons |
| Drift / freshness alerts | Event-driven triggers + schema-drift detection | dbt tests (you build them) | Not native — governance process |
| Governance depth | Moderate — honestly, not Looker-grade | Good (version-controlled) | Excellent (certified metrics, row-level security) |
| Setup effort | Same day — connect and define | Needs a mature dbt project underneath | Weeks of LookML modeling |
| Best fit | Small / mid teams wanting the outcome, not a program | Teams already living in dbt | Large orgs with a dedicated data team |
| Rough cost (team of 5) | Free tier, paid from $49/mo | Included in dbt plans | $50–100k/yr |
What this is not
We would rather you buy the right thing.
Knowing the boundaries before you start saves a bad evaluation. Here is where Fastero's metrics layer is the wrong tool:
Not Looker-grade governance
If you need certified-metric row-level security for 200 analysts and a compliance auditor, buy Looker or AtScale. We will tell you so. Fastero is the lightweight version for teams who want one definition and drift alerts, not a governance program.
Not a magic auto-updater
We do not pretend definitions heal themselves. Fastero detects drift and alerts you — a human still decides the fix. That is the honest, verifiable version of “keeps itself current.”
Not a fix for messy data
A metrics layer on top of an unreconciled warehouse is just a mapping tax. If the underlying data needs cleaning first, the definitions will be brittle — fix the data, then define on top of it.
Cross-source joins are roadmap, not today
Fastero defines and queries metrics on your connected warehouse. Stitching a single definition across separate SaaS tools (e.g. Stripe and HubSpot) is on the roadmap, not a current claim. We would rather under-promise here.
A cautionary tale
One wrong definition nearly made us celebrate a fake 100% activation rate.
We counted the wrong event, and our activation metric quietly approached 100%. The dashboard was correct. The query ran fine. The definition underneath was wrong — and nothing in the tooling was going to catch it. It is exactly why we built drift detection into the metrics layer.
Read the storyFAQ
Frequently asked questions.
How is this different from dbt or a full semantic layer?
If you already run dbt, its Semantic Layer is a great fit and Fastero can sit alongside it. Fastero is for teams who want the outcome — one definition, self-serve answers, drift alerts — without standing up and maintaining that infrastructure themselves. See our honest tool comparison for the full landscape.
Does it stop the AI from hallucinating numbers?
It reduces it sharply by constraining the AI to your defined logic and showing the generated SQL for verification — but no tool eliminates it. Fastero is built for human-in-the-loop on high-stakes numbers, not blind trust.
Can it join data across my tools, like Stripe and HubSpot?
Today Fastero defines and queries metrics on your connected warehouse. Cross-source stitching across separate SaaS tools is on our roadmap, not a current capability — we would rather be honest about that than overclaim.
What exactly does “drift detection” catch?
It watches the schemas and pipelines your definitions depend on. When an upstream column is renamed, a table changes, or a pipeline stops updating, you get an alert. That is schema and freshness drift on the data side — the early-warning signal that a definition is about to go wrong.
Do I need a data engineer to set this up?
No. Connecting a warehouse and defining your first metrics is a same-day job for anyone comfortable with SQL. Most teams start with their top 15–25 most-argued-about metrics and expand from there.
Is this a replacement for our BI tool?
Not necessarily. Many teams keep their dashboards and use Fastero for the definition layer, natural-language answers, and drift alerts. It is designed to complement your stack, not force a rip-and-replace.
Related pages
Stop arguing about whose number is right.
Define your metrics once, let your team ask in plain English, and get alerted when a definition starts to drift. Free to start — no credit card required.