You don't need YAML to define your metrics

Every semantic layer tool on the market starts the same way: open a YAML file, define your metrics, map the joins, deploy the model. Cube, dbt, LookML: they all assume you have someone on the team who can write and maintain these definitions. For most startups, that assumption is wrong.

The YAML tax

Writing metric definitions in YAML isn't hard if you know SQL and understand the schema. The problem is maintenance. Every time a column is renamed, a table is added, or a business definition changes, someone has to update the YAML. Miss one, and your metrics silently break.

# cube.js metric definition
cubes:
  - name: orders
    sql_table: public.orders
    measures:
      - name: revenue
        sql: amount
        type: sum
        filters:
          - sql: "{CUBE}.status = 'completed'"
    dimensions:
      - name: created_at
        sql: created_at
        type: time

This is fine for one metric. Now multiply it across 50 tables, hundreds of columns, and dozens of relationships. You're not defining metrics anymore. You're maintaining a parallel model of your entire database. That's a full-time job.

Who this actually works for

YAML-based semantic layers work well when you have:

• A data team of 3+ people who own the definitions
• A mature warehouse with stable schemas
• Multiple downstream consumers (dashboards, notebooks, APIs) that need identical metrics
• The discipline to treat your semantic layer as a codebase, with PRs, reviews, and CI

If you have all four, a hand-built semantic layer is a genuine competitive advantage. But most teams under 50 people have zero of these.

The real question

The goal of a semantic layer is consistent metrics. When your CEO asks “what's our revenue?” and your ops lead asks the same question, they should get the same number. YAML is one way to achieve that. It's not the only way.

What if you could get the same consistency without writing a single line of config?

Auto-generated metric definitions

Contextflo reads your database schema and auto-generates table descriptions, column meanings, relationships, and metric definitions. You review them, tweak anything that's off, and you're done. The AI uses these definitions every time someone asks a question, so “revenue” always means the same thing.

The definitions live in Contextflo and are served to Claude (or any LLM) as context with every query. No YAML files to version. No deployment pipeline. No drift between your semantic layer and your actual schema, because the definitions are generated from the schema itself.

What you lose (and what you don't)

A hand-built semantic layer gives you fine-grained control over every edge case. You can define complex calculated metrics, time-zone handling, and custom aggregation logic that no auto-generator would infer.

What you don't lose is consistency. The whole point (making sure everyone gets the same answer) works the same way whether the definitions were written by an analytics engineer or generated from your schema and refined by you.

For most teams, the 80/20 is clear: auto-generated definitions cover 80% of what you need, and the remaining 20% can be handled by adding custom descriptions or metric definitions as you encounter edge cases. No upfront YAML project required.

Try it

Connect your database to Contextflo, let it generate your metric definitions, and start asking questions. If you're spending time writing YAML instead of getting answers, you're solving the wrong problem.