Thin layer, thick warehouse: what not to copy

Your warehouse already does hard work. Storage, joins, retention, access control, and compute scheduling live there for good reason. A semantic layer that tries to re-implement those jobs becomes a second warehouse with worse tooling and a shorter memory.

datahashi is a thin layer on top of what you already run. Metrics and dimensions are declared in YAML, reviewed like code, and published as an immutable version. Humans and agents then call the same metric definitions through REST, the console, or MCP, with the same request shape. The goal is one governed surface for numbers, not a parallel copy of your data platform.

What stays in the warehouse

Keep grain-defining facts, foreign keys, and historical snapshots in the warehouse. That is where large joins, late-arriving facts, and partition pruning belong. If a transformation is about cleaning raw events into a trustworthy table, that work is warehouse work.

Also keep policy that is about rows: who can see which customers, which regions, which tenants. Warehouses already have mature patterns for masking, row filters, and role grants. A semantic layer should respect those boundaries, not invent a second permission model that drifts from them.

What belongs in the semantic layer

Put metric meaning in the semantic layer: the official definition of revenue, active users, conversion rate, or pipeline coverage. That includes the measure expression, the allowed dimensions, the time grain, and whether the metric is safe to sum across certain keys.

YAML is the contract. You declare metrics once, publish an immutable version, and every consumer (analyst, dashboard, or agent) hits that version. You do not paste SQL into chat tools and hope the next run matches last week’s dashboard.

datahashi metering exists so you can see how metrics are used. Rollups have shipped for repeated questions. A p99 latency target has not. The thin layer earns trust by staying thin: one definition path, not a second compute engine competing with your warehouse.

What not to copy

Do not copy dimension tables into the semantic layer “for convenience.” Do not duplicate join logic in both dbt models and metric YAML so that either side can “win.” Do not recreate warehouse access rules as ad hoc filters inside every agent prompt.

The failure mode is familiar: two teams report the same named metric with different SQL, then argue about which export is correct. Copying logic into the layer multiplies that risk. Declaring metrics once and serving them through one API shrinks it.

Same request shape everywhere

When an analyst opens the console, a service calls REST, or an agent uses MCP tools like list_catalog, describe_metric, and run_semantic_query, the request shape stays consistent. Agents do not invent SQL. They ask for governed metrics. Humans get the same answers without hand-written query variants.

That is the product truth in one line: same metric for humans and agents, without hallucinated SQL.

A practical split

If changing a definition should require a review and a new published version, it belongs in YAML. If changing a pipeline should rebuild tables and partitions, it belongs in the warehouse. If you are tempted to copy a join “just this once” into both places, stop and pick one owner.

Thick warehouses hold data. Thin semantic layers hold meaning. datahashi is built for the second job, on purpose.