ClickHouse Semantic Layer
ClickHouse semantic layer for TypeScript teams
Most teams searching for a ClickHouse semantic layer are trying to solve one of two problems. Either they need a full semantic platform for BI and shared metrics, or they need one place to define queries that can be reused safely across APIs, jobs, dashboards, and app code. hypequery is built for the second case.
Primary fit
Typed query-contract layer
Platform comparison
Lighter than Cube / MetricFlow
Best audience
TypeScript teams on ClickHouse
A ClickHouse semantic layer can mean several different products
Sometimes the goal is centralized BI metrics for many consumers. Sometimes it is one reviewed query definition that can be reused inside a product codebase. Those overlap, but they are not the same tool.
Full semantic platforms solve a broader problem than many app teams need first
Cube and dbt MetricFlow are strong when you need centralized metrics, broader semantic modeling, multiple non-engineering consumers, or platform-level governance. Many ClickHouse teams are earlier than that and mainly need reusable typed query contracts inside a TypeScript stack.
Raw SQL is not a semantic layer just because it is shared in a few places
Even correct ClickHouse SQL drifts once the same logic is copied into dashboards, endpoints, exports, and product code. The first useful layer is a named query with typed inputs and a stable output shape.
What hypequery gives you
One query definition that can travel across your stack
hypequery lets you define named ClickHouse queries in TypeScript, validate inputs, infer outputs from the schema, and reuse that same definition across local execution, HTTP endpoints, React hooks, and agent-facing surfaces. For many product teams, that is the useful part of the semantic-layer problem.
- Schema-generated types from your live ClickHouse database
- Named query definitions instead of anonymous SQL fragments
- Typed inputs with Zod and typed outputs from the query result
- One contract reused across services, dashboards, internal tools, and app features
- A clean path to HTTP, OpenAPI, React, and agent-facing consumers
- A lighter operational footprint than running a separate semantic platform
Named contract
Define a metric-like query once
This is the workflow hypequery supports well today: define a query once, type it from the live schema, and reuse it across consumers without re-authoring the logic.
Where the line is
Use hypequery for product delivery, and reach for Cube or dbt MetricFlow when semantic governance is the product
The honest line is simple. If you need centralized metrics for BI tools, richer semantic modeling, or a dedicated platform that serves many non-engineering consumers, evaluate Cube or dbt MetricFlow. If you need reusable query definitions inside a ClickHouse-heavy TypeScript product, hypequery is the lighter fit.
A lot of teams searching for "ClickHouse semantic layer" are really trying to stop duplicating query logic across codepaths. hypequery addresses that directly by making queries first-class and reusable.
If your world is BI tooling and centrally managed metric definitions, Cube and dbt MetricFlow are better search paths. If your world is shipping ClickHouse-backed features in TypeScript, hypequery is usually closer to the problem you actually have today.
Reuse pattern
One definition, several delivery paths
This is the practical payoff: the same query definition can feed server code, REST endpoints, dashboards, and agent workflows without being rewritten in each place.
Where teams usually get stuck
The questions this page should answer
ClickHouse semantic layer
The key question is whether you need a full semantic metrics platform or a reusable application-layer contract for queries and metric-shaped outputs.
dbt MetricFlow alternative for TypeScript apps
dbt MetricFlow is stronger when semantic modeling and broader analytics governance are the main job. hypequery is the lighter code-first option when your main need is governed ClickHouse query reuse inside TypeScript.
Reusable metrics on ClickHouse
Reusable metrics start with named queries, typed inputs, and consistent delivery paths. That is the part hypequery solves directly for ClickHouse applications today.
Cube alternative for ClickHouse-backed apps
Cube is a stronger fit for a fuller semantic platform. hypequery is the lighter fit when the main need is reusable query contracts, typed APIs, and application delivery on top of ClickHouse.
Further reading
Go deeper where it actually helps
The analytics language layer essay
The broader argument for why reusable governed query contracts matter in modern analytics stacks.
Open guide
ClickHouse Analytics
The practical product page for building a reusable analytics layer on ClickHouse.
Open guide
hypequery vs Cube
A direct comparison between a code-first query layer and a fuller semantic-layer platform.
Open guide
ClickHouse Query Builder
See the lower-level query composition layer that sits underneath reusable contracts and typed delivery paths.
Open guide
ClickHouse MCP
How defined query contracts become safer AI-agent tools than raw SQL exposure.
Open guide
Next step
Decide whether you need a query-contract layer or a full semantic platform
If repeated query logic inside your app is the main problem, start with the analytics layer. If you need deeper semantic capabilities, compare Cube and then decide whether your team is solving app delivery or broader semantic governance.