Semantic layer vs warehouse-native semantics

Warehouses increasingly ship “semantic” features: metric views, governed tags, AI query helpers tied to one vendor’s SQL dialect. Those features help inside that console. They are a weak foundation when the same number must leave the warehouse for BI, apps, and MCP agents - or when you might change warehouses.

datahashi is a portable serving layer in front of your warehouse, not a second copy of your transforms and not a vendor-locked metric store.

What warehouse-native semantics optimize for

Vendor-native semantics usually optimize for analysts who already live in that product:

• Definitions expressed in that warehouse’s SQL or proprietary metric DSL
• Discovery and lineage inside that vendor’s UI
• Sometimes an assistant that writes SQL against those objects

That is useful. It is also coupled. Your “certified” revenue definition becomes hard to reuse from a React app, a second BI tool, or an MCP agent that must not see free-form SQL. Swap Snowflake for BigQuery (or add a second engine for a subsidiary) and the semantic surface tends to fork.

What a portable semantic layer optimizes for

A serving layer like datahashi optimizes for one request shape across consumers:

• Author the model once as YAML: entities, dimensions, measures, metrics
• Publish an immutable artifact (model plus policy bundle, versioned and frozen)
• Query via REST/console or MCP with the same structured Semantic Query object
• Compile to the warehouse you connected (nine engines, including Snowflake, BigQuery, Postgres, and MySQL)

Callers name metrics and dimensions. They never invent joins. Fan-out-safe SQL runs in your warehouse. Nothing is copied out for serving unless you declare a rollup; a rollup stores a pre-aggregated result on the engine side, built through the same runner.

Thin layer, warehouse holds transforms

Portable does not mean “move the dbt project into the semantic tool.” Currency conversion, recognition rules, and heavy staging stay in the warehouse. The semantic model maps tables to business terms, declares relationships, and exposes certified metrics. Governance (field grants, row-level rules, cost ceilings) is applied on every read as part of the request path - not as a filter after someone already ran arbitrary SQL.

That split keeps the layer maintainable and keeps you honest about latency: you are pushing down compiled SQL, metering bytes and rows, and adding rollups only for the questions that are actually hot.

Agents make portability non-optional

MCP agents do not want a Snowflake worksheet. They need a catalog of metric names and a run_semantic_query-style tool that cannot accept SQL. Warehouse-native assistants that emit dialect SQL recreate the failure mode teams already know: confidently wrong joins and dashboards that disagree.

With datahashi, agents call list_catalog, describe_metric, and run_semantic_query. Humans use the same metric names in the playground. Same published version, same number.

When native is enough

If one warehouse UI is your only consumer, and no agent or external app needs the same certified metrics, native features may be enough for a while. The moment you need multi-consumer sameness - BI plus app plus agent, or multi-warehouse portability - a serving layer that sits in front of the warehouse pays for itself.

Use the warehouse for storage and transforms. Use a portable semantic layer when the metric must travel.