Define the metric once. Every tool agrees.
datahashi is a semantic layer. Dashboards, apps and AI agents ask for a metric by name and get the same answer back.
Dashboard tile config
tile: Revenue, EU metric: revenue filter: region = EU period: 2026-09
Compiled SQL, parameterized
SELECT SUM(o.amount) - SUM(r.amount) AS revenue FROM analytics.orders o LEFT JOIN analytics.refunds r ON r.order_id = o.id WHERE o.status = 'completed' AND o.region = $1 -- "EU" AND o.ordered_at BETWEEN $2 AND $3
01One definition
Stop arguing about which number is right
Today each tool writes its own SQL for revenue, and each gets a slightly different answer. Write the definition once instead.
Three tools, three answers
Each wrote its own SQL.
One file, one answer
metric: revenue
expression: sum(orders.amount) - sum(refunds.amount)
filters: [orders.status = 'completed']
owner: financeEdit the YAML and all three change together.How the model works →
02For agents
Agents get answers, not access
Three things hold for every agent request. Try each one.
Agents can't write SQL
They ask for metrics, dimensions and filters. Raw SQL, invented joins and unknown fields are refused.
Agent asks for SQL
tool: query_metric args: { "sql": "SELECT SUM(amount) FROM orders" }
✗ raw SQL is not accepted
Agent asks by name
tool: query_metric args: { "metrics": ["revenue"] }
✓ 1,284,930 · example data
The password stays in your network
A Query Runner beside your warehouse holds the password, the kill switch and the audit log. The engine only sends it SQL.
Stage 1 of 4
Caller
Asks for a metric by name. Never writes SQL.
✗Never holds a warehouse key.
Receives
# a question, asked by metric name
Passes on
{ "metrics": ["revenue"],
"filters": [{ "region": "EU" }] }
Authorization: Bearer <JWT or API key>Stage 2 of 4
Engine
Checks the credential, applies grants and row rules, then writes the SQL.
✗Never sees the warehouse password.
Receives
semantic query + credential
Passes on
SELECT SUM(o.amount) ... WHERE o.region = $1 + runner key
Stage 3 of 4
Query Runner · yours
Runs the SQL with a read-only role. Keeps the password, the kill switch and the audit log.
✓Holds: password, kill switch, audit log.
Receives
bound SQL + runner key
Passes on
native connection (read-only role)
Stage 4 of 4
Warehouse · yours
Returns rows to the runner. Only the runner can connect.
✓Your data never leaves your side as a copy.
Receives
read-only connection
Passes on
rows (not kept by the engine)
Repeat questions skip the warehouse
A short result cache and rollups answer common questions without a fresh scan. Speed figures come once a benchmark exists.
First ask
Same ask again
Row rules, scoped keys and short-lived tokens decide who sees what.Agents →Security →
03Free or hosted
Run it yourself, or let us
The same engine either way. Hosted plans charge for metrics and agents, not seats.
On your own servers. One model, one folder.
- You run the engine and the Query Runner
- REST and MCP
- No control plane, no seats
We run the engine. Starter, Growth or Enterprise.
- Up to 150 metrics on Growth, plus SSO
- Enterprise: hosted, or in your cloud
- Paid pilot: $1,500/mo for 4–6 weeks
Every plan, side by side.Pricing →
Start with one metric
Three steps to your first governed answer.
- Step 1Run a Query Runner next to your warehouse.
- Step 2Publish a model of your metrics.
- Step 3Query over REST or MCP.