CBoard: a self-service OLAP dashboard platform you extend in Java

Two audiences in one product: the analyst and the Java developer

CBoard is described as a self-service BI reporting and dashboard platform, and the README positions it for two different users at once. A normal user analyses data and designs reports through drag and drop. A developer can extend any data source they can connect with a Java program.

That second role is the more unusual one and the reason the project is worth looking at. The stated argument is that no commercial BI suite can connect all the NoSQL and NewSQL data sources, because their schemas differ so much, hash tables, arrays, trees and maps, and the person who knows a storage schema best is the person who uses it. So CBoard leaves that part of the work to the end user and supplies an extension framework for it.

The consequence is that CBoard is not a sealed product. It is a Java application whose data access layer is a plugin point, and the deployment you end up with is defined by which providers you implement. The README's own pitch is that the entire project does not rely on any third-party multidimensional analysis tool, and that it could be an alternative for people struggling with Mondrian.

The product comes from Shanhai Chuguo Information and Technology Co., Ltd., and the homepage is www.chuguotech.com.

The engine is CBoard's own, not a Mondrian or a Kylin underneath

The architecture section of the README claims a light weight architecture, a common technology stack, a self designed multi-dimension engine and a small application running on your big data stack. The distinguishing claim is the last one about dependencies: the whole project avoids third-party multidimensional analysis tools.

That single decision shapes the feature set in a way that is easy to miss when reading the feature list. There is no OLAP server to license, no separate cube build step, and no second system to keep in sync. What you get instead is the report development experience: interactive drag-and-drop report design in what the README calls an OLAP classic style, one dataset reused across multiple report widgets to maximise reuse of query results, cube level data refresh and realtime charts for quick queries, and role based access control.

The chart library is broad, more than 20 chart types, and there are dashboard insight and email report features on top. The reuse claim is the one to check in a pilot. If a dashboard shows the same slice several ways, the question is whether the cube is recomputed or the cached result is reused, and the README asserts the latter without describing the cache invalidation rules.

For a team already running Mondrian, this is the comparison the README invites. The trade is direct: no OLAP engine to operate, but also no mature query planner underneath, and the whole multidimensional logic sits in this codebase.

Three built-in connection types, and a DataProvider for the rest

The built-in connectors cover three kinds of source, and the README is specific about versions. JDBC covers almost any database that implements the JDBC protocol. Native Elasticsearch connections are supported for version 1.x, 2.x and 5.x. Native Kylin connection is supported for version 1.6.

Those version pins are the first thing to check against your estate. An Elasticsearch 7 or 8 cluster is not in the list, so a team on a current cluster falls back to the JDBC path, which means an Elasticsearch JDBC driver and a different modelling approach for the same data. The Kylin support is pinned to 1.6, which is a specific release of an Apache project that has moved on.

The extension mechanism is the DataProvider. The README frames the design decision this way: NoSQL schemas vary widely, the users who know their own schema are the users themselves, and it is easy to find a Java programmer who can code a class to connect their own data source. So the platform hands over an easy extended data connection framework instead of trying to anticipate every storage engine.

In practice that means the realistic evaluation question is not which databases CBoard supports, but how hard it is for your team to write and maintain a provider for the one database that is missing. The Java codebase is described as concise, and the source layout follows a Maven project with pom.xml, src/, lib/, sql/ and a Dockerfile at the root.

Building the image today means an old base image and a WAR file

There is no installation guide in the README beyond the container route, so the Dockerfile is the only concrete deployment artifact available. It starts from centos:6.9, which reached end of life years ago, and replaces the CentOS base repository with a mirror from mirrors.163.com before installing packages:

FROM centos:6.9

Java 8 is installed, and Tomcat 8.5.23 plus PhantomJS 2.1.1 are downloaded and extracted into /opt. Chinese fonts are installed for the rasterisation PhantomJS performs, and a set of 32-bit libraries is added for the same reason. The application itself arrives as a prebuilt WAR:

ADD cboard.war /opt/apache-tomcat/webapps/cboard.war

The container ends with a shell rather than a Tomcat entrypoint:

CMD ["/bin/bash"]

Two commented commands at the end of the file show the intended run pattern, and the port mapping in them is the only port the project mentions:

docker build --network=host -t cboard .
docker run --rm -itd --name=cboard -p 8026:8080 --privileged=true cboard

The image therefore expects you to start Tomcat yourself, and the --privileged flag in the sample command is a requirement the project does not explain. The --network=host flag on the build is there because the build downloads Tomcat and PhantomJS over the network.

The honest read is that this Dockerfile was written for a 2018 era host. It will not build unchanged on a current machine, and getting it to build is part of the adoption work rather than a step you can assume.

The community and enterprise split is the upgrade path you are choosing

The README carries a long comparison table between the Community Edition and the Enterprise Edition, and it is the most decision-relevant part of the document for anyone evaluating the open source build. A community edition and a vendor-backed edition is a common shape for Chinese enterprise software, and here the vendor sells the extra capabilities rather than the core.

What both editions share is the bulk of the platform: multiple kinds of data source plugins, drag-and-drop self-service multidimensional analysis, more than 20 chart types, dashboards, near-realtime data refresh, and email reports.

What the enterprise edition adds is substantial. Cockpit dashboard, inline chart insertion in dashboards, regrouping dimension members, custom sort of dimension members, a detail data table, a GIS map chart on detail data, cell-level data security with role based data access control, an OS-like file system for resources with ACLs managed by folder, advantage cross tables with year-on-year and percentage calculations and cell conditional styles, dashboard iframe integration with parameter control, SDK integration support, a VueJS and ES6 and Webpack front end instead of AngularJS, professional production support, and a customer-oriented road map.

The community edition is explicitly maintenance-oriented while the enterprise road map is customer-oriented, and the community edition does not have inline charts, so all charts must first be saved and managed in the Widget Config design area. Read that list against your own requirements before you assume the open source build covers them.

The project itself says it was unmaintained, and that is the central risk

The first thing in the README is a project update, and it should be the first thing an evaluator reads. The project says CBoard has been unmaintained for quite a long time, and that limited resources and business challenges meant it could not give the project the attention it deserves. It then says that with the rise of Vibe Coding the maintainers are excited about the possibility of bringing CBoard back to life, and that they plan to resume development and gradually improve the project.

So the status is ambiguous in a specific way. The repository is not archived and the last push was on 2026-10-17, which is recent. The code is moving. But there are no GitHub releases at all, so there is no tagged version to pin to, and the default branch is named branch-0.4.2 rather than main, which is itself a signal that the branch layout has not been tidied up.

The topics list mentions metabase and superset alongside olap and big-data, and the README's alternative-to-Mondrian pitch places CBoard in the same category as those tools. That comparison is fair in architecture terms, since both are self-service BI tools, but a reader should weigh it against the maintenance statement above rather than against the features table.

The licence is Apache-2.0, which is permissive and lets a company modify, deploy and redistribute the project without copyleft obligations. The commercial relationship is separate: the maintainers sell the enterprise edition and host a SaaS product through a partner.

When CBoard is the wrong choice

There are clear cases where this project is the wrong tool, and the comparison table and the maintenance notice together name most of them.

If your users need cell-level data security, an OS-like resource permission model, inline charts in dashboards, or a detail data table, the community edition does not provide them. The enterprise edition does, and that is a commercial relationship rather than a build-it-yourself exercise. An organisation with a data governance regime that requires row and column level access control will not get it from the open source build.

If your Elasticsearch cluster is version 7 or later, the native connector does not cover it and you are in JDBC territory. If your analytical engine is a current Kylin release, the native connection is pinned to 1.6.

If you need a service with a support contract, a security patch process and a documented upgrade path, the project tells you plainly that it has not been able to maintain the community version with the attention it deserves, and the table lists professional support as an enterprise-only item.

There is also a category of problem CBoard is honest about not solving. Connecting every NoSQL and NewSQL source is left to the end user by design, so an unusual data source means writing and owning Java code, which is a fine answer for a company with Java developers and a bad answer for one without.

Editorial conclusion

CBoard fits a Java team that wants a self-hosted drag-and-drop reporting tool and is prepared to write a DataProvider class for a database the connectors do not cover, and it does not fit a team that needs an actively maintained product with a documented upgrade path, because the README states the project was unmaintained for a long time and the repository publishes no GitHub releases. Verify three things before adopting it: that the JDBC driver for your database is present, that the Docker build still works on a current base image since the committed Dockerfile is based on centos:6.9, and that the community edition features your users need are not on the enterprise-only list. The licence is Apache-2.0, the default branch is branch-0.4.2, and the last push was on 2026-10-17.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. TuiQiao/CBoard on GitHub