How to Set Up a Semantic Layer Without dbt Cloud

You don't need dbt Cloud to get a working semantic layer. Define your metrics in YAML, point your AI agent and dashboards at those definitions, and every query in your org computes "revenue" or "churn" the same way. Fastero's built-in semantic layer does this without a separate deployment, a MetricFlow server, or a $100/seat/month contract.

This guide walks through the full setup: writing metric definitions, importing existing dbt metrics, adding validation rules, and connecting the semantic layer to an AI agent that respects your definitions when it writes SQL.

Why does "MRR" mean three different things in your company?

You've sat in this meeting. Marketing's MRR includes trial-to-paid conversions dated to signup. Finance excludes them until the first payment clears. The product dashboard counts annual contracts at 1/12th; Finance counts them at invoice value. Three dashboards, three numbers, one term.

A semantic layer fixes this by making "MRR" resolve to one definition everywhere. Dashboards, SQL editor, AI chat, scheduled reports — all query against the definition rather than each re-deriving the metric from scratch.

Here's what that architecture looks like:

┌──────────────┐
│  Your data   │   Postgres, Snowflake, BigQuery, etc.
└──────┬───────┘
       │
       ▼
┌──────────────┐
│  Semantic    │   YAML metric definitions
│  Layer       │   + dbt metric import
│              │   + validation rules
└──────┬───────┘
       │
       ├──→ Dashboards (governed metrics, not ad-hoc SQL)
       ├──→ SQL Editor (autocomplete resolves to definitions)
       ├──→ AI Agent  (NL2SQL uses defined logic, not guesses)
       └──→ Scheduled Reports / Alerts

What are the alternatives, and what do they cost?

Four paths to a semantic layer in 2026:

dbt's semantic layer is excellent if you're already on dbt Cloud Team or Enterprise. But if you're on dbt Core, or you're not using dbt at all, you're paying $100+/seat/month just to get MetricFlow queries. Cube is powerful but it's another service to deploy and maintain. AtScale is enterprise-grade and priced accordingly.

Fastero takes a different approach: the semantic layer ships inside the same platform where you build dashboards, run SQL, and talk to the AI agent. No extra deployment. If you already have dbt metric definitions, you import them. If you don't, you write them directly. For the full eight-tool comparison, see the best semantic layer tools of 2026.

How do you define a metric?

Each metric is a YAML definition. Five fields matter:

metric: mrr
aliases: [monthly_recurring_revenue, MRR]
description: >
  Sum of active subscription amounts, normalized to monthly,
  excluding trials and one-time charges.
sql: |
  SELECT
    date_trunc('month', s.period_start) AS month,
    SUM(s.amount_cents) / 100.0         AS mrr
  FROM subscriptions s
  WHERE s.status = 'active'
    AND s.plan_type != 'trial'
    AND s.charge_type = 'recurring'
  GROUP BY 1
grain: monthly
owner: finance-team
source_table: subscriptions
last_reviewed: '2026-08-01'

The aliases field is what makes this work with the AI agent. When a stakeholder asks "what's our MRR?", the agent matches "MRR" to this definition and uses the exact SQL logic instead of guessing. The owner field means someone gets pinged when the underlying schema changes.

Start with the 10-15 metrics that cause fights. Revenue, churn, active users, conversion rate. The metric definition guide walks through how to pick them.

How do you import existing dbt metrics?

If you've already defined metrics in dbt's semantic_models and metrics YAML, you don't rewrite them. Fastero imports them:

# fastero-config.yaml
dbt_import:
  project_path: ./dbt_project
  metric_paths:
    - models/marts/finance/semantic_models.yml
    - models/marts/product/semantic_models.yml
  sync: on_commit   # re-import when dbt models change

The importer reads MetricFlow-style definitions (dimensions, measures, entities) and maps them to Fastero's metric format. Your dbt model stays the source of truth for transformations; Fastero's semantic layer becomes the query interface. Governance policies and validation rules don't carry over — those you add in Fastero, because dbt doesn't have equivalents.

How does the AI agent use the semantic layer?

This is the part that changes how your team works. Without a semantic layer, when someone asks "show me revenue by region for Q2," the AI agent has to guess which table is "revenue," whether it includes refunds, what the date field is, and whether "region" lives on the customer table or the order table.

With the semantic layer, the agent doesn't guess:

User: "What was MRR last quarter?"
 
Agent resolves: "mrr" → metric definition → governed SQL logic
 
Agent generates:
  SELECT month, mrr
  FROM (
    SELECT date_trunc('month', s.period_start) AS month,
           SUM(s.amount_cents) / 100.0 AS mrr
    FROM subscriptions s
    WHERE s.status = 'active'
      AND s.plan_type != 'trial'
      AND s.charge_type = 'recurring'
    GROUP BY 1
  ) base
  WHERE month >= date_trunc('quarter', now() - interval '3 months')
    AND month < date_trunc('quarter', now())

An agent with a semantic layer returns the number your CFO expects. An agent without one returns a plausible number that might be off by 20% because it included trials. The NL2SQL engine does the translation; the semantic layer tells it what the words mean.

How do you prevent definitions from going stale?

Metric definitions rot. Someone renames a column in your CRM, a new pricing tier appears, Finance quietly changes how they handle foreign currency. Your semantic layer is now confidently wrong — the worst kind of wrong.

Fastero handles this with validation rules and policy governance:

metric: mrr
validations:
  - type: not_null
    columns: [amount_cents, period_start, status]
  - type: accepted_values
    column: status
    values: [active, canceled, past_due, trialing]
  - type: row_count_minimum
    threshold: 100
    alert: slack:#data-alerts
policies:
  - access: org_wide           # everyone can query this metric
  - mutation: finance-team      # only finance can edit the definition
  - drift_alert: on            # notify owner on upstream schema changes

If subscriptions.status suddenly has a value your definition doesn't account for — say the billing system adds a paused status — you get an alert before the board meeting, not during it. The full validation playbook is in how to validate metric definitions across your data team.

Policy governance controls who can query a metric vs. who can change it. Your whole org can ask "what's MRR?" but only the finance team can modify the definition.

What does the full setup look like?

  ┌─────────────┐       ┌─────────────────┐       ┌───────────────┐
  │ Connect     │       │ Define or       │       │ Query via     │
  │ your data   │ ────→ │ import metrics  │ ────→ │ any surface   │
  │ sources     │       │ (YAML or dbt)   │       │               │
  └─────────────┘       └────────┬────────┘       └───────────────┘
                                 │
                        ┌────────▼────────┐
                        │ Validation +    │
                        │ drift detection │
                        │ runs on schedule│
                        └─────────────────┘

Five steps, roughly 30 minutes for your first metric:

1. Connect your database. Postgres, Snowflake, BigQuery, MySQL, or any of Fastero's 40+ connectors.
2. Write or import metric definitions. YAML files directly, or import from an existing dbt project.
3. Add validation rules. Column-level checks, row count thresholds, accepted value constraints.
4. Set governance policies. Who can query, who can edit, who gets drift alerts.
5. Start querying. Dashboards, SQL editor, AI agent, and scheduled reports all resolve against the governed definitions.

The cached metric store pre-computes common aggregations so your dashboards don't re-run the full query on every page load. A metric like MRR that scans millions of subscription rows shouldn't re-execute every time someone opens the executive dashboard.

FAQ

Do I need dbt to use Fastero's semantic layer? No. dbt import is one of two paths. You can define metrics directly in YAML or through the UI without any dbt project. The semantic layer works identically either way — you just skip the import step.

Can I use Fastero's semantic layer alongside my existing BI tools? Yes, through Fastero's public API. Your existing dashboards can query governed metrics via REST endpoints. But the most value comes when dashboards, SQL, and the AI agent all live in the same platform and resolve against the same definitions.

How is this different from just writing SQL views? Views give you reusable SQL but no governance, no validation, no alias resolution for AI agents, and no drift detection. A semantic layer adds the meaning — who owns it, what values are valid, when it was last reviewed, and how the AI should interpret it. Views are a piece of the puzzle; the semantic layer is the frame.

What happens when my dbt models change? If you set sync: on_commit, Fastero re-imports metric definitions whenever your dbt project updates. If a dbt model change breaks a metric (renamed column, dropped measure), the validation rules catch it and alert the metric owner before anyone queries stale data.

Does the AI agent always use the semantic layer? The agent checks the semantic layer first. If a user's question matches a defined metric by name or alias, the agent uses the governed definition. If there's no matching metric, it falls back to schema-aware SQL generation but flags that the query isn't backed by a governed definition.

Try Fastero free — define your metrics once, import from dbt if you have them, and let your AI agent query governed definitions instead of guessing. No credit card required.