# DataGear treats the dashboard as an HTML file you are allowed to edit

> DataGear is an LGPL-3.0 Java data visualisation platform built as a single Spring Boot application with an embedded Derby database, where dashboards are native HTML pages with a visual designer and a source editor side by side. It reaches any JDBC database by dropping in a driver at runtime.

**datageartech/datagear** — DataGear数据可视化分析平台，自由制作任何您想要的数据看板

- Repository: https://github.com/datageartech/datagear
- Website: http://www.datagear.tech
- Stars: 1,748 · Forks: 383
- Language: Java
- License: LGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/datageartech-datagear

## Dashboards are HTML documents, which is the decision everything else follows from

DataGear's dashboards are native HTML web pages used as templates. You can import any HTML, JavaScript or CSS, design them visually, and also edit the source freely.

That single choice explains most of the platform's character. It is why the frontend stack lists Vue3, PrimeVue, jQuery, CodeMirror and ECharts together: they coexist in a page rather than being unified into one framework. It is also why the README notes you can bring in Vue, React, Bootstrap or Tailwind CSS to build dashboards with rich interaction and multi-device adaptation.

Both editing modes are first class. There is a visual design mode and a source editing mode, demonstrated in the screenshots as a dashboard editor animation. For a tool whose users are often analysts rather than engineers, having a source escape hatch is the difference between a platform people can adapt and one they work around.

The dashboard feature list follows directly: importable HTML templates, responsive layout across phone, tablet, desktop and large screen, a share password, and iframe embedding. The iframe and password pair is how a dashboard leaves the application, which is a pragmatic answer to a question many BI tools handle with a more elaborate mechanism.

The README also claims a built-in dashboard API supporting chart linking, data drill-down, asynchronous loading and interactive forms, and the screenshot directory includes animations for each: map chart linking, real-time charts, drill-down, forms and linked asynchronous chart loading. Those are the five capabilities that separate a dashboard tool from a chart gallery.

## Any database, by adding a JDBC driver at runtime

The extensibility claim is specific rather than aspirational: DataGear supports adding data source drivers at runtime, and therefore any database that provides a JDBC driver library.

The README names the ones it expects people to use: MySQL, PostgreSQL, Oracle, SQL Server, Elasticsearch, ClickHouse, plus domestic Chinese databases including OceanBase, TiDB, Kingbase and Dameng.

The module structure explains where this happens. datagear-connection is the database connection support module, and it defines the API for loading JDBC drivers from a specified directory and creating new connections. Loading from a directory rather than from a bundled classpath entry is what makes runtime addition possible at all, and it is also why the feature list mentions data source driver management as a first-class function alongside datasource management.

Around that sit three more modules with the same layered shape: datagear-meta parses the table structure of a given data source, datagear-persistence reads, edits and queries datasource table data, and datagear-dataexchange handles importing and exporting data for a specified datasource.

The pattern is worth internalising. Introspection, data access and bulk movement are separate modules from the service layer in datagear-management, which means a replacement for any one of them is a bounded task rather than a rewrite.

## Datasets are the query layer, and they accept six kinds of input

Between the datasource and the chart sits the dataset, and the README describes it as accepting SQL, HTTP, CSV, Excel, JSON and file sources, with support for defining parameters and parameterised syntax.

There is also a dedicated SQL workbench alongside datasource management, so the SQL path is treated as a first-class workflow rather than a form field.

Datasets support SQL, HTTP, CSV, Excel, JSON and files. That list matters because a chart in DataGear can bind multiple datasets from different sources within one chart, which is what makes cross-source comparison possible without a data warehouse in between.

The parameterisation feature is the part that turns datasets into something reusable. A dataset with a parameter and a parameterised syntax becomes a query template: one dataset definition, many filtered views, driven from dashboard interactions. That is what the drill-down and form screenshots depend on, and it is the closest thing DataGear has to a semantic layer.

For context, the README's feature list runs: datasource management with create, read, update, delete, import, export and the SQL workbench; dataset management; chart management; dashboard management; user management; role management; datasource driver management; and chart plugin management. Charts come with more than seventy ready-to-use built-in types.

Chart plugins are user-extensible in both directions. You can write and upload a custom chart plugin to add a chart type, and you can also rewrite and extend the built-in plugins, plus customise chart options. On a repository with no GitHub releases, that extension path is arguably the more important part of the project.

## A single application with an embedded Derby, which simplifies deployment and complicates upgrades

DataGear is described as a privately deployed, monolithic application with a lightweight architecture, simple installation, and the runtime environment and data entirely under your control.

The persistence story supports that. The stack lists Spring Boot, Mybatis, Freemarker, Derby, Jackson, Caffeine and Spring Security. Derby is the embedded database, and the debug notes pin its location exactly: the built-in database sits under `[用户主目录]/.datagear/derby`.

An embedded database is why the deployment story is short. There is no separate database server to provision before the first start. The cost is in upgrades, and the README is unusually candid about it.

The system automatically upgrades the built-in database according to the current version number at startup, and does not run that upgrade again on subsequent starts once it has succeeded. If you hit a database problem while debugging, the instruction is to look in the DDL file at `datagear-management/src/main/resources/org/datagear/management/ddl/datagear.sql`, find the SQL statements you need, and run them by hand, then manually update the version marker:

```sql
UPDATE DATAGEAR_VERSION SET VERSION_VALUE='4.6.0'
```

There is a helper class for exactly this, `org.datagear.web.util.DerbySqlClient`, which the README says can be run directly from the IDE, with the caveat that DataGear must be stopped first.

There is a second warning, and it is more dangerous. Before debugging on a `dev-*` branch, back up the DataGear work directory, because a development branch modifies that work directory at startup and can prevent both the previously used release version and later releases from starting normally.

That is the operational shape: trivial to install, and manual to repair if an upgrade goes wrong.

## Building from source needs a MySQL 8.0 test database before mvn will pass

The compile section requires you to prepare a unit test environment first, which is unusual enough to follow exactly.

Install MySQL-8.0 and set the `root` user's password to `root`, or modify the configuration in `test/config/test.properties` instead. Create a test database named `dg_test`. Initialise it using the `test/sql/test-mysql.sql` script.

Then build:

```bash
mvn clean package
```

If you would rather not set up the test database, the README gives an alternative that skips tests:

```bash
mvn clean package -DskipTests
```

The package lands in `datagear-webapp/target/datagear-[version]-packages/`. That path tells you the artefact is the `datagear-webapp` module, which matches the module list where `datagear-webapp` holds the program startup class.

For debugging rather than packaging, the instructions are to import `datagear` into an IDE as a Maven project, run the startup class `org.datagear.webapp.DataGearApplication` in debug mode, and open `http://localhost:50401` in a browser.

The declared dependencies are minimal: Java 8+ and Servlet 3.1+. That floor is worth noting for a Spring Boot application, since it means the project targets a broad runtime range rather than a recent JDK only.

The top level also carries `Roadmap.txt`, `RELEASE.md` and a `screenshot/` directory, though the README does not describe their contents, and the project states that DataGear 6.1.0 is available for download from the official site.

## Security posture: private by default, with injection and encryption handled explicitly

The README lists its security measures in one dense line, and each item maps to a real category of problem in a BI tool.

越权访问校验 is unauthorised access validation, which is the check that a user cannot read a dataset or dashboard they were not granted. 数据源防护 is datasource protection. SQL防注入 is SQL injection defence, which for a tool where the analyst writes raw SQL by hand is the load-bearing one: any platform that lets users type SQL against a datasource and only protects the management database has not solved the problem.

敏感信息加密存储 is encrypted storage of sensitive information, which in practice means datasource credentials. 日志脱敏处理 is log desensitisation, so a password or token typed into a datasource form does not end up in a log file.

The authorisation model is described as role-based, with data private by default and shareable or shareable-in-common. Share password and iframe embedding are the two sharing mechanisms named in the feature list. Combined with the private-by-default posture, that is a reasonable shape for an internal analytics tool where dashboards get linked into other systems.

What is not described is a row-level or column-level security model over query results, nor any audit trail of which user ran which SQL. If your data has per-row visibility rules that vary by user, the role model plus the parameterised dataset support may or may not be enough, and the README does not settle it.

Do not read the fact that the project has run stably for thousands of hours as a security review. It is a stability claim.

## Two editions, and where this repository sits

The README links two products from the same site, and the distinction is a real adoption input.

DataGear 6.1.0 is announced as released and available from the official site, http://www.datagear.tech, which is also the project homepage. A separate DataGear enterprise edition 1.5.0 is announced as formally released at a `/pro/` path with a trial offered.

So the open source repository and the enterprise product are versioned separately, and the open source line is at 6.1.0 while the enterprise line is at 1.5.0. 

Licensing is LGPL-3.0, stated in the copyright section as the standard GNU Lesser General Public License, either version 3 of the License or, at your option, any later version. The repository root carries `COPYING`, `COPYING.LESSER`, `LICENSE` and `NOTICE`, which is the file set the LGPL expects.

On maintenance: the repository is not archived and the last push was on 2026-10-12, so development is current. There are no GitHub releases, so there is no tag to pin and no changelog through GitHub; `RELEASE.md` and `Roadmap.txt` exist in the repository but the README does not describe them.

For an LGPL component that you deploy unmodified and access over HTTP, the licensing question is usually straightforward. If you intend to modify it, read the LGPL terms themselves rather than relying on that summary.

## Conclusion

Adopt DataGear if you need a self-hosted BI tool for a team already inside JDBC-land, on Java 8 or newer, where the analyst should be able to drop a driver jar in and edit the dashboard HTML directly. Do not adopt it expecting a governed semantic layer, a query engine that optimises across sources, or a pure cloud deployment story, since the README describes data private by default with sharing by password or iframe rather than a row-level permission model. Verify first that your database offers a JDBC driver you can load into `datagear-connection`, and read the debug warning about the work directory at `[用户主目录]/.datagear` before running any `dev-*` branch against a machine that holds real DataGear data.

## FAQ

### Which databases can DataGear connect to?

Any database providing a JDBC driver library, by adding the driver at runtime. The README names MySQL, PostgreSQL, Oracle, SQL Server, Elasticsearch, ClickHouse, and Chinese databases including OceanBase, TiDB, Kingbase and Dameng.

### How do DataGear dashboards work?

A dashboard is a native HTML web page used as a template. You can import any HTML, JavaScript or CSS, edit it in a visual designer or directly in source, and the layout is responsive across phone, tablet, desktop and large screen.

### How do I build DataGear from source?

Set up a MySQL-8.0 instance with the root password `root`, create a database named `dg_test`, initialise it with `test/sql/test-mysql.sql`, then run `mvn clean package`. Or use `mvn clean package -DskipTests` to skip the test environment.

### What are the Java requirements for DataGear?

The README lists Java 8+ and Servlet 3.1+. Debugging runs the startup class `org.datagear.webapp.DataGearApplication` and opens `http://localhost:50401`.

### Where does DataGear store its own data?

In an embedded Derby database under `[用户主目录]/.datagear/derby`. The system upgrades it automatically at startup based on the version number, and if that fails the README tells you to run the needed SQL by hand and update the marker with `UPDATE DATAGEAR_VERSION`.

### Can I add my own chart types to DataGear?

Yes. The README states you can write and upload custom chart plugins to extend the system, and also rewrite and extend the built-in chart plugins with custom chart options. More than seventy ready-to-use charts ship built in.

## Sources

- [datageartech/datagear on GitHub](https://github.com/datageartech/datagear)
- [Issues](https://github.com/datageartech/datagear/issues)
- [License: LGPL-3.0](https://github.com/datageartech/datagear/blob/master/LICENSE)
- [Project website](http://www.datagear.tech)
- [README](https://github.com/datageartech/datagear/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/datageartech-datagear