The semantic layer

One governed model.
Every consumer, the same right number.

DataHashi sits between your warehouse and everything that queries it — LLMs, BI tools, embedded apps, internal services — so nobody recomputes the same metric a different way.

Connect a warehouse See a live query →
p99 ≤ 14ms
semantic-query.json → compiled.sql
You send

  "metrics": ["average_order_value"],
  "dimensions": ["customer.region"],
  "grain": "month"
We run
SELECT date_trunc('month', o.order_date),
  c.region, SUM(o.amount)/COUNT(o.id)
FROM rollup_orders o
JOIN dim_customer c ON ...
-- served from a rollup, not the warehouse
Fan-out-safe SQL Sub-second rollups Tenant-isolated
Works with your stack
Snowflake BigQuery Postgres MySQL DuckDB / lake
One picture

Every consumer speaks business terms.

LLMs, BI tools, embedded apps, and internal services all ask DataHashi the same way — a metric, a dimension, never a join or raw SQL. DataHashi resolves that against one governed model and compiles the correct, dialect-specific SQL for whichever warehouse actually holds the data.

Many consumers, one governed model, many sources LLMs and agents, BI tools, embedded apps, and internal services all send DataHashi the same kind of request: business terms, like a metric and a dimension, never a join or raw SQL. DataHashi resolves that request against one governed semantic model and compiles it into correct, dialect-specific SQL, pushed down to whichever warehouse actually holds the data — Snowflake, BigQuery, Postgres, MySQL, or a DuckDB lake. CONSUMERS · same request shape YOUR SOURCES · unmoved LLMs & Agents via MCP tools BI Tools dashboards, notebooks Embedded Apps in-product analytics Internal Services REST DataHashi one governed model metrics · dimensions Snowflake BigQuery Postgres MySQL DuckDB / Lake business terms — never raw SQL compiled SQL, pushed down
Consumers never see a table or a join — they ask for a metric by name. DataHashi is the only thing that ever touches your warehouses, and it only ever sends them compiled, correct SQL.
The problem

Built for teams done writing the same join twice.

SQL sprawls across dashboards, notebooks, and app code. Definitions drift, LLMs invent joins and return confidently-wrong figures, and the warehouse bill keeps climbing. DataHashi puts one governed model in the middle — and pushes the hard parts down to where they belong.

Less, but better

Name the metrics you want. You never write a join or an aggregation by hand.

Correct by design

Fan-out-safe SQL and governed metrics — the same number everywhere.

Sub-second

Answered from pre-aggregated rollups. p99 ≤ 14ms, never touching the warehouse.

Pushed down

Processing happens in the database. The layer stays thin; the source does the work.

Go deeper

One thesis, four angles.

Same governed model, same compiler — see it from wherever you're standing: how you'd set it up, what's inside it, what a query looks like, and how it stays fast.

How it works

Connect a warehouse, publish a model, query it — four steps, no config files or restarts.

See onboarding →

Platform

The governed model, the join graph, sub-second rollups, MCP for agents, and tenant isolation.

See the platform →

Query interface

A Semantic Query in, correct dialect-specific SQL out — every consumer sends the same shape.

See a live query →

Architecture

Two paths, opposite profiles — sub-second embedded reads, durable async rollup builds.

See the architecture →
Get started

Put one governed model between your data and everything.

Connect a warehouse, bless a model, and start serving sub-second, governed numbers to your LLMs, dashboards, and apps.

Console See how it works

No credit card · Bring your own warehouse · Self-serve onboarding