TL;DR Verdict
Cube Dev scores 7.5 out of 10 for teams managing metrics across multiple BI tools and customer-facing apps. It is the right call for data engineering teams who are tired of rewriting the same revenue calculation in three different places. It is not the right call for a solo analyst who just wants a Looker Studio dashboard by Friday. Biggest strength: a single, versioned data model that keeps metric definitions consistent everywhere. Biggest weakness: the schema learning curve adds real friction in the first two weeks.
What Cube Dev Actually Is
Cube Dev is an open-source semantic layer platform. You can think of it as a translation layer that sits between your data warehouse and every downstream tool that consumes data, whether that is a BI dashboard, a React app, or an embedded analytics widget.
The core idea is straightforward. Instead of writing SUM(revenue) / COUNT(orders) in five places, you define average_order_value once inside Cube Dev. Every tool that connects to it, Metabase, Superset, a custom API call, pulls from that single definition. When the business changes the rule for how revenue is counted, you update one file.
The company behind this is Cube Dev Inc., founded in 2019 by Artyom Keydunov and Pavel Tiunov. The product started life as Cube.js, a JavaScript-first headless BI framework. By 2026 it has matured considerably. The open-source repo has north of 17,000 GitHub stars, the cloud product has paying enterprise customers, and the team ships meaningful updates on a regular cadence.
It is not a BI tool in the traditional sense. You will not get pre-built charts or a drag-and-drop dashboard builder out of the box. Cube Dev exposes REST, GraphQL, and SQL APIs. Your visualization layer is a separate concern. That separation is precisely what makes it powerful for certain teams, and completely overkill for others. If you want context on how it compares to traditional BI stacks, the headless BI explained guide on this site covers the architecture well.
The product targets data engineers, analytics engineers, and platform teams at companies where more than one team is building on top of the same data warehouse.
Pricing And Plans
Cube Dev has two distinct tracks: the open-source self-hosted version and Cube Cloud, the managed service.
The open-source version is free. Fully. You run it on your own infrastructure, you manage the deployment, and you get all core features including the semantic layer, query rewriting, and multi-source joins.
Cube Cloud is where things get nuanced. There is a free Starter tier that covers small teams and experimentation, with limited compute resources and no SLA. The Production tier starts at around $399 per month and unlocks autoscaling, production-grade infrastructure, and priority support. Enterprise pricing is custom and negotiated directly with the sales team, typically adding SSO, audit logs, dedicated infrastructure, and compliance features.
The gotcha most people hit is compute credits. Cube Cloud bills on a credit model tied to the number of Cube instances running and how long queries take. A busy multi-tenant setup can burn through the included credits faster than expected, and overages are not cheap. Read the pricing page carefully before you assume the mid-tier plan covers your usage pattern.
| Plan | Price | Hosting | Key Limits |
|---|---|---|---|
| Open Source | Free | Self-hosted | You manage infra |
| Starter (Cloud) | Free | Managed | Limited compute credits |
| Production (Cloud) | ~$399/month | Managed | Autoscaling, SLA |
| Enterprise (Cloud) | Custom | Managed or dedicated | SSO, audit logs, compliance |
For a startup that can manage its own Kubernetes or Docker setup, the open-source path is genuinely competitive. For a team that wants to skip DevOps entirely, budget for at least the Production tier from day one.
Setup Experience
The first 30 minutes with Cube Dev have a predictable shape. You install it via Docker or npm, connect your first data source, and then hit your first schema file. That schema file is where most people slow down.
Cube Dev uses JavaScript or YAML files to define your data models, called Cubes. A Cube maps to a table or view in your warehouse and contains measures, dimensions, and join relationships. The syntax is learnable, but it is not intuitive coming from SQL. A measure like count_of_orders requires you to declare a type, a SQL expression, and optionally filters, all in a structured format that feels foreign for the first hour.
The documentation is genuinely good. The Cube Dev docs cover schema basics, deployment options, and API references with real examples. The gap is in the intermediate content. Once you move beyond a single Cube and start defining cross-Cube joins or pre-aggregations, the official docs get thinner and you end up in GitHub issues and community Slack threads.
The Cube Cloud onboarding flow is more guided. You get a connection wizard for your warehouse, a schema generator that tries to introspect your database tables, and a data model playground where you can run test queries before you expose anything to a downstream tool. The generator saves time but produces schema files that need manual cleanup. It will not know that your orders table needs a join condition filtered on deleted_at IS NULL.
Docker-based local setup takes about 20 minutes for someone comfortable with containers. The first real data model, tested end to end, realistically takes a full afternoon. That is not unusually slow for infrastructure tooling, but set the right expectations with your team before the first sprint.
For more on evaluation approaches for this category, see the data modeling tools compared breakdown.
What It Does Well
Single Source of Truth for Metrics
The core value proposition holds up in practice. Once you define a measure in Cube Dev, every tool consuming that measure gets the same number. If your revenue metric changes because you now exclude refunds, you update one line in one schema file. Downstream tools pick it up without anyone touching their dashboard. For teams where data inconsistency between the sales dashboard and the finance dashboard has caused actual arguments in meetings, this is the feature that justifies the investment.
Pre-aggregations and Query Acceleration
Cube Dev’s pre-aggregation engine builds materialized rollup tables in your warehouse on a schedule you define. A query that would normally scan 500 million rows gets answered from a pre-aggregated summary table in milliseconds. This is not a caching gimmick. It is a legitimate query optimization layer that makes Cube Dev viable for customer-facing analytics where sub-second response times matter. You define the rollup in your schema file and Cube Dev handles the refresh, the query routing, and the fallback logic automatically.
Multi-Source Joins
Connecting measures from two different databases or schemas in a single query is where most warehouse-native approaches fall apart. Cube Dev handles cross-source joins at the semantic layer by federating the query. You can join a PostgreSQL users table with a BigQuery events table inside a Cube schema and expose it through a single API endpoint. The complexity is hidden from whoever builds the dashboard or writes the API call.
REST, GraphQL, and SQL APIs
The three-API approach means Cube Dev fits into almost any architecture. A React developer can hit the REST API with a JSON query spec. A data analyst can connect via the SQL API using any tool that speaks Postgres wire protocol, including Excel, DBeaver, or even psql. A mobile app can query GraphQL. You define the data model once and every consumer type is served without extra work.
Row-Level Security
Cube Dev’s security context system lets you inject user attributes into every query at the semantic layer. You define a SECURITY_CONTEXT variable in your schema and use it to filter data by user ID, tenant, region, or any attribute passed in the JWT token. This is essential for multi-tenant SaaS applications where different customers must only see their own data. Implementing it at the semantic layer means you cannot accidentally build a dashboard that leaks data across tenants.
Developer-Friendly Workflow
Schema files live in your git repository. That means peer review, branching, rollback, and CI/CD integration are all natural. You can preview schema changes in a development environment before deploying to production. For teams that have already invested in dbt or other analytics engineering workflows, Cube Dev slots in as the API layer on top of your dbt models without much friction.
Where It Falls Short
YAML and JavaScript Schema Complexity
The schema files grow fast. A mid-size data model with 15 Cubes, multiple joins, and a few dozen pre-aggregations becomes genuinely hard to navigate. There is no visual schema editor that keeps up with power users. You end up maintaining a mini-codebase just to describe your data, and that codebase needs documentation and ownership the same way application code does.
No Built-In Visualization
Cube Dev deliberately does not include a charting layer. That is the right architectural call for platform teams. For everyone else, it means you are always assembling a stack. You need Cube Dev plus something else, Metabase, Superset, a custom frontend, whatever fits. If your team is small and your timeline is short, the extra integration step is a real cost.
Pre-aggregation Gotchas
Pre-aggregations are powerful but brittle when your schema changes. Adding a new dimension to a Cube that has existing pre-aggregations often triggers a full rebuild. A rebuild on a large table can run for hours and temporarily degrade query performance. Planning pre-aggregation strategy takes experience, and getting it wrong in production is painful.
Learning Curve for Non-Engineers
If your BI team is mostly analysts rather than engineers, expect a rough first month. The concept of defining measures in code before you can chart them is a workflow shift. Analysts used to dragging fields into Tableau do not naturally reach for a YAML file. Training and documentation investment is non-negotiable for this audience.
Pricing Opacity at Scale
The credit-based pricing on Cube Cloud makes budget forecasting harder than it should be. Small teams experimenting on the Starter plan often get a surprise when they move a workload to Production and realize their query patterns are more credit-intensive than they modeled. Better tooling for cost estimation before you upgrade would help.
Best Alternatives To Consider
dbt Semantic Layer (MetricFlow) is the closest architectural peer. If your team already uses dbt for transformation, the dbt Semantic Layer adds metric definitions inside your existing dbt project without a new runtime to manage. The trade-off is less flexibility in API types and a tighter coupling to the dbt ecosystem. Worth evaluating first if dbt is already in your stack.
Looker with LookML is the established enterprise option. Looker is both a semantic layer and a BI tool, which removes the “no visualization layer” problem. The trade-off is cost, vendor lock-in, and a proprietary modeling language. Looker makes sense if you have a Google Cloud commitment and a budget north of $3,000 per month.
Lightdash is an open-source BI tool that reads your dbt models and exposes them as a drag-and-drop interface. If you want the semantic layer benefits of dbt with a built-in chart layer for analysts, Lightdash closes that gap. It is lighter and easier to operate than Cube Dev but gives you less API flexibility.
AtScale targets large enterprises with complex multi-cloud data estates. It covers similar ground to Cube Dev but with more emphasis on enterprise governance, MDX compatibility, and connecting to legacy BI tools like Excel PivotTables and Power BI. If those are requirements, AtScale is worth a look.
For a side-by-side comparison of several of these tools, the best BI tools for startups post covers the decision criteria in more depth.
Who Should Use Cube Dev
The Analytics Engineering Team at a Series B Startup
If you are an analytics engineer or data engineer supporting a growing product team, and you have five or more dashboards in three different tools all computing the same metrics slightly differently, Cube Dev solves a real problem you are already feeling. You need a platform that fits into a git workflow, works with your existing warehouse, and gives product and finance teams consistent numbers. Cube Dev is a natural fit here, especially if you can tolerate the schema learning curve in the first sprint.
The SaaS Company Building Embedded Analytics
If you are building a SaaS product and you need to embed charts or tables showing each customer their own data, Cube Dev’s API-first approach and row-level security model are precisely what you need. You call the Cube Dev API from your backend, pass the tenant context in the JWT, and every customer sees only their data. Building this yourself on raw SQL takes weeks. Cube Dev gets you there in days.
The Platform Team Standardizing Across Business Units
If you run a data platform team at a company where multiple business units each have their own analysts and BI tools, and leadership keeps complaining that the numbers do not match between divisions, a centralized semantic layer is the correct architectural answer. Cube Dev lets each business unit keep their preferred BI tool while pulling from a shared, governed metric store. The investment is real but the payoff in reduced “which number is right” meetings is measurable.
Frequently Asked Questions
Is there a free version of Cube Dev?
Yes. The open-source version is completely free and includes all core semantic layer features. You host it yourself on Docker, Kubernetes, or a VPS. Cube Cloud also has a free Starter tier for smaller workloads, though it has compute credit limits.
How hard is it to learn Cube Dev if I mostly know SQL?
The SQL API means you can query Cube Dev using standard SQL syntax, which lowers the initial barrier. Writing schema files is a different skill, closer to configuration-as-code than to writing queries. Budget a full week for a SQL-proficient analyst to get comfortable with schema authoring.
Does Cube Dev integrate with Metabase or Superset?
Yes to both. Cube Dev exposes a SQL API that speaks the Postgres wire protocol, and both Metabase and Superset can connect to it as a Postgres data source. Cube Dev also has a native connector for Superset in more recent versions.
Can I migrate from Looker LookML to Cube Dev?
There is no automated migration tool. The concepts map reasonably well, Explores become Cubes, measures and dimensions carry over in concept, but you will rewrite the schema files by hand. Expect a migration project measured in weeks, not hours.
What happens if I outgrow the free Starter tier on Cube Cloud?
You upgrade to the Production plan. Your schema files and configuration carry over without changes. The main difference is compute capacity and the inclusion of an SLA. Cube Dev’s own support team can help you right-size the plan before you commit.
Bottom Line
Cube Dev is the right tool when you have a real consistency problem across multiple data consumers and the engineering capacity to maintain a schema codebase. It is overkill if your analytics stack is one tool and one team. The open-source version gives you a genuine no-cost path to production, which is rare in this category. The Cube Cloud pricing needs careful modeling before you commit to the Production tier.
Score: 7.5 out of 10. Recommended for data engineering teams, analytics platform teams, and SaaS companies building embedded analytics. Not recommended for analysts who just need a faster path to a chart.
Want to try Cube Dev? Start with Cube Dev and see if it fits.