Cube Core: the open source semantic layer behind Cube
📊 Cube Core is open-source semantic layer for AI, BI and embedded analytics
At a glance
- What is it?
- Cube Core defines metrics, dimensions, joins and access rules once in code and serves them over SQL, REST and GraphQL. It is headless by design, and development mode is an authentication bypass you must never expose.
- Who is it for?
- Adopt Cube Core if you are building your own analytics surface and want one governed model served over SQL, REST and GraphQL, and if you can run the server yourself. Do not adopt it if you want a ready-made BI platform with dashboards, RBAC and multi-tenancy out of the box; the README points that audience at Cube instead.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Cube Core solves for BI, embedded analytics and AI agents
Every BI tool has a semantic layer inside it, and that layer is where metric definitions, dimensions and business logic live. The README makes the consequence explicit: most of these layers are proprietary and tied to one BI platform, so the same model has to be rebuilt for every other tool that needs it. Cube Core takes that layer out of the BI tool and makes it a standalone service. You define metrics, dimensions, joins and access rules once in code, and the server exposes them through SQL, REST and GraphQL to whatever sits downstream: a BI tool, a custom application, or an AI agent.
The intended audience is not the analyst who wants a dashboard today. It is the team building the analytics experience itself. The README describes Cube Core as headless, meaning it ships no user interface, so the product surface is yours to build. That is a deliberate trade: you get control over the presentation layer and the model, and in exchange you own the surrounding platform work. The repository topics list embedded analytics, headless BI and conversational analytics alongside the warehouse names, which matches the README's framing that the same model should serve internal BI, embedded analytics and AI agents without re-implementation.
How the semantic layer serves SQL, REST and GraphQL from one model
The architecture is a server in front of your SQL data sources. The README says Cube Core works with all SQL data sources and names cloud warehouses like Snowflake, Databricks and BigQuery, query engines like Presto and Amazon Athena, and application databases like Postgres. Your metric definitions live in code in the project directory, and the server compiles incoming requests into SQL against the connected source.
Between the API and the warehouse sits a relational caching engine. The README states it is built in and exists to provide sub-second latency and high concurrency for API requests. That is the part that matters operationally: without a cache, every dashboard refresh and every agent question becomes a warehouse query, and concurrency costs money. The README does not document cache invalidation strategy, TTL configuration or how the cache behaves when a source table changes outside the model, so treat those as things to establish from the documentation before you size a deployment.
The repository layout backs the multi-language claim. The root package.json declares workspaces covering both rust/* and packages/*, and the primary language reported for the repository is Rust, while the published server package is @cubejs-backend/server on npm. The client libraries sit under packages/, which is why the README can point at React, and the examples directory holds recipes rather than a single reference app.
Installing Cube Core with Docker and reaching the playground
The README gives one Docker command as the fastest path. It mounts your current directory into the container as the configuration directory, publishes the API port and the SQL port, and turns on development mode. Run it in a new folder for your project.
docker run -p 4000:4000 \
-p 15432:15432 \
-v ${PWD}:/cube/conf \
-e CUBEJS_DEV_MODE=true \
cubejs/cubePort 4000 is the API and the setup UI. Port 15432 is the SQL endpoint. After the container starts, the README says to open http://localhost:4000 in a browser to continue setup. That page is the playground, and it is where you connect a data source and start writing the model. The docs link at docs.cube.dev/cube-core/getting-started/create-a-project is the step-by-step version of the same flow.
The README also mentions install-cli.sh and install-cli.ps1 at the repository root, so there is a CLI installer path in addition to Docker, though the README does not walk through it. What the README does document at length is the warning attached to that command, and it deserves its own section.
CUBEJS_DEV_MODE is an authentication bypass, not a convenience flag
This is the most important paragraph in the README, and it is easy to skim past. In the official images, whose entrypoint is the cubejs CLI, setting CUBEJS_DEV_MODE=true also forces NODE_ENV=development, which switches off JWT verification on the REST (JSON) and GraphQL APIs. Those APIs then accept requests with no token at all. Playground and its supporting endpoints are served with no authentication either, so anyone who can reach the instance is handed a ready-to-use API token and can mint others carrying any security context, signed with your API secret. They can read your data model, overwrite it, and overwrite your .env file.
It gets worse on the SQL side. With no CUBEJS_SQL_PASSWORD set, the SQL API accepts any credentials, which the README says allows arbitrary SQL against connected data sources. That is not a subtle misconfiguration; it is the documented behaviour of the flag.
The README states this is intentional. Development mode is designed to run on a developer's local machine for ease of use and debugging. It says never to expose it to the internet or use it in production, and that using it in the Cube cloud platform is highly discouraged because it bypasses the platform's security model. One detail worth internalising: Cube is also in development mode whenever NODE_ENV is not production, but cubejs server and the official images already set NODE_ENV to production. So the risk concentrates in the Docker quickstart and in any custom container that forgets to set NODE_ENV.
Where Cube Core is the wrong choice, and what Cube adds instead
Cube Core does not ship a UI, dashboards, workbooks, managed deployment, RBAC or multi-tenancy. The README is direct about this when it separates the two products. Cube is the commercial product built on the same semantic layer, and the README lists what it adds: Analytics Chat, workbooks and dashboards, embedded analytics surfaces, managed deployment, RBAC, multi-tenancy, and integrations with Tableau, Power BI, Excel and Google Sheets. If any of those is the thing you actually need, Cube Core is the wrong starting point, and the README says so rather than leaving you to discover it.
The compatibility claim is worth noting because it changes the switching cost. The README states the data model is fully compatible both ways: a model you build in Cube Core runs unchanged in Cube, and vice versa. Cube Core stays open source and is what the vendor says it runs inside Cube itself. So the choice is not about the model, it is about how much surrounding platform you want to build.
The other honest boundary is operational. A headless server in front of your warehouse means you own deployment, upgrade cadence, cache behaviour and the security configuration described above. Teams that want a governed metric layer but have no appetite for running a service should read the Cube Core versus Cube section of the README before writing any model code.
Release cadence, licence and the cost of staying current
Maintenance is not in question here. The repository is not archived, and the last push was on 2026-09-15. Recent releases run close together: v1.7.38 on 2026-09-14, v1.7.37 on 2026-09-10, and v1.7.36 on 2026-09-09. Three patch releases inside a week tells you the project ships often, and it also tells you an upgrade policy matters more than usual. Pinning to a specific patch and reading CHANGELOG.md before moving is the practical posture; the repository keeps a CHANGELOG.md at the root and a DEPRECATION.md alongside it, which is where breaking changes should surface.
On licensing, the repository reports the licence as NOASSERTION, which means GitHub could not map the LICENSE file to a known identifier. That is a fact about the repository metadata, not a statement about the terms. If you are embedding Cube Core in a commercial product, read the LICENSE file and the SECURITY.md and DCO.md files at the root yourself, and get your own legal read. Nothing here substitutes for that, and the README does not summarise the licence terms.
The upgrade cost is mostly the model and the deployment, not the API surface. Because the model is portable to Cube and back, a model that works today is unlikely to be stranded. What needs attention on each bump is the container configuration, particularly the NODE_ENV and CUBEJS_DEV_MODE settings, since those decide whether authentication is enforced at all.
Editorial conclusion
Adopt Cube Core if you are building your own analytics surface and want one governed model served over SQL, REST and GraphQL, and if you can run the server yourself. Do not adopt it if you want a ready-made BI platform with dashboards, RBAC and multi-tenancy out of the box; the README points that audience at Cube instead. Before you commit, verify that your deployment never runs with CUBEJS_DEV_MODE=true and that NODE_ENV is production, because in development mode the REST, GraphQL and SQL APIs accept unauthenticated requests.
Frequently asked questions
What is Cube Core used for?
It is an open source semantic layer. You define metrics, dimensions, joins and access rules once in code, then expose them through SQL, REST and GraphQL APIs to BI tools, custom applications or AI agents. The README describes it as headless, so it ships no UI.
What does a cube mean in analytics?
In Cube Core the term refers to the semantic layer's data model, where metrics, dimensions and joins are defined in code rather than inside a BI tool. The README frames the semantic layer as the component every BI tool relies on as its core engine.
How do I install Cube Core?
The README gives a single docker run command using the cubejs/cube image, publishing ports 4000 and 15432, mounting your project directory at /cube/conf and setting CUBEJS_DEV_MODE=true. You then open http://localhost:4000 to continue setup.
Is CUBEJS_DEV_MODE safe to use in production?
No. The README states that in the official images CUBEJS_DEV_MODE=true also forces NODE_ENV=development, which switches off JWT verification on the REST and GraphQL APIs, serves Playground without authentication, and with no CUBEJS_SQL_PASSWORD set lets the SQL API accept any credentials. It says never to expose it to the internet or use it in production.
What is the difference between Cube Core and Cube?
Cube Core is the open source semantic layer. Cube is the commercial product built on it, adding Analytics Chat, workbooks and dashboards, embedded analytics surfaces, managed deployment, RBAC, multi-tenancy and integrations with Tableau, Power BI, Excel and Google Sheets. The README states the data model is compatible both ways.
Community notes