Cube.js Alternative
Looking for a Cube.js alternative for ClickHouse?
Cube is good at what it does. It's also a lot: a server to deploy, a cache layer to run, and a modelling language to learn. If you're a TypeScript team shipping ClickHouse-backed product features, hypequery covers the part you actually use — typed queries, typed APIs, and React hooks — as a plain library in your own repo.
Infrastructure
None — npm library
Modelling
TypeScript, not YAML
Best fit
ClickHouse-backed product features
Cube is a platform you have to operate
A production Cube deployment means the Cube API server, a Cube Store or Redis cache layer, and schema config deployed alongside both. That is a lot of operational surface when what you actually have is a handful of product queries.
The data model lives outside your application
Cubes, measures, and dimensions sit in YAML or JS config, in a separate modelling layer. Your app then talks to them through Cube-specific query JSON — one more contract to keep in sync with the code that actually uses the data.
TypeScript is a second-class consumer
Cube serves REST, GraphQL, and SQL APIs, but none of the response types come from your ClickHouse schema. So teams hand-maintain interfaces for Cube responses — which is the exact drift problem a semantic layer was supposed to fix.
The alternative
A code-first typed layer instead of a semantic layer platform
hypequery replaces the Cube server with a library. Types come from your live ClickHouse schema, queries are TypeScript, and serving them as APIs is one function call — no separate deployment, cache cluster, or modelling language.
- Generate TypeScript types from your live ClickHouse schema — no YAML modelling layer
- Define metrics as typed, composable query builder code in your own repo
- Serve queries as REST endpoints with validation and OpenAPI docs via @hypequery/serve
- Consume the same typed contracts in React with generated hooks
- Ship it like any other code change — no Cube deployment to coordinate
Step 1
Generate types instead of modelling cubes
Your ClickHouse schema is already the data model. hypequery introspects it and generates types that match runtime behaviour, so there’s no second modelling layer to maintain.
Step 2
Metrics become typed queries in your codebase
What Cube expresses as measures and dimensions in config, hypequery expresses as query builder code — reviewable in PRs, refactorable with your editor, and type-checked against the real schema.
Worth saying plainly: Cube is still the right call if you need BI tool connectivity (Tableau, Metabase, Superset over its SQL API), pre-aggregations feeding many consumers, or one metrics layer across several databases. hypequery is ClickHouse-only and application-first, on purpose.
But if your Cube deployment exists to power your own product dashboards and APIs on ClickHouse, a typed library is less to run, less to learn, and closer to your code.
Step 2
A measure, without the modelling layer
Aggregations, time bucketing, and filters are typed against your generated schema. Runtime parameters like date ranges and tenant IDs are ordinary function arguments.
Side by side
Cube vs hypequery at a glance
The short version: Cube is a platform between your databases and many consumers. hypequery is a library between your ClickHouse and your application.
| Cube | hypequery | |
|---|---|---|
| Runs as | Separate API server plus Cube Store or Redis cache | A library inside your existing Node.js app |
| Data modelling | Cubes, measures, and dimensions in YAML or JS config | TypeScript query code, checked against your real schema |
| Response types | Hand-written interfaces for Cube query responses | Generated from your live ClickHouse schema |
| Databases | Many — Postgres, BigQuery, Snowflake, ClickHouse, more | ClickHouse only, by design |
| BI tool access | SQL API for Tableau, Metabase, Superset | Not a goal — typed application APIs instead |
| Caching | Pre-aggregations and caching built in | Bring your own, or use ClickHouse materialized views |
| Shipping a change | Update schema config, redeploy the Cube service | Normal pull request in your app repo |
| Cost | Open source, with Cube Cloud as the managed option | Free and open source |
If the left column reads like a list of things you rely on — multiple databases, BI consumers, heavy pre-aggregation — stay with Cube. This page is for teams who noticed they only use the right column.
Where teams usually get stuck
The questions this page should answer
Open source Cube.js alternative
hypequery is free and open source. Nothing is gated behind a hosted tier — the query builder, serving layer, OpenAPI generation, and React hooks are all in the packages.
Cube.js alternative without extra infrastructure
The most common reason teams go looking for an alternative is operational weight. hypequery has no server component: it runs inside your existing Node.js application and talks straight to ClickHouse.
Semantic layer for ClickHouse in TypeScript
If your metric definitions should live in TypeScript next to the code that uses them — with compile-time checking against the real schema — that’s the workflow hypequery is built around.
When Cube is still the right answer
Multiple databases, BI tool consumers, or heavy pre-aggregation needs are Cube territory. hypequery deliberately trades that breadth for a lighter, ClickHouse-native developer experience.
Further reading
Go deeper where it actually helps
hypequery vs Cube
The full comparison covering setup, workflow, and where each tool is the right choice.
Open guide
ClickHouse semantic layer
How a code-first semantic layer works when ClickHouse is the only database that matters.
Open guide
ClickHouse REST API
How @hypequery/serve turns query definitions into validated, documented endpoints.
Open guide
ClickHouse React hooks
Consume the same typed query contracts from dashboards and product UI.
Open guide
Next step
Test the lighter path against one real metric
Generate types from your ClickHouse schema and rebuild one Cube measure as a typed query. That’s the fastest way to see whether you need the platform or just the layer.