# DataCap: one query surface across dozens of datastores

> DataCap is a Java platform for querying, transforming and visualising data held in many different engines at once, from ClickHouse and Presto to MongoDB, Kafka and Neo4j. The repository ships a multi-module Maven build, a Docker image and a compose file that wires the server to MySQL and ClickHouse.

**devlive-community/metaforge** — DataCap is integrated software for data transformation, integration, and visualization. Support a variety of data sources, file types, big data related database, relational database, NoSQL database, etc. Through the software can realize the management of multiple data sources, the data under the source of various operations conversion ...

- Repository: https://github.com/devlive-community/metaforge
- Website: https://datacap.devlive.org/
- Stars: 1,057 · Forks: 136
- Language: Java
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/devlive-community-metaforge

## What DataCap is built to do

DataCap is described as integrated software for data transformation, integration and visualisation. It supports a variety of data sources, file types, big data databases, relational databases and NoSQL stores, and the README lists what that enables: managing multiple data sources at once, applying various operations to the data under each source, making charts, and monitoring data sources.

The pitch is one interface over data that is scattered across engines. A company might hold transactional rows in MySQL, analytical tables in ClickHouse, query results in Presto or Trino, documents in MongoDB, a graph in Neo4j and an event stream in Kafka. Each has its own client, its own dialect and its own tooling. DataCap gives those a common place to be queried and visualised.

The project is Apache-2.0 licensed, written in Java, and served at datacap.devlive.org. The releases are dated by year and number rather than semver, with 2025.1.1 published on 2025-07-28, 2025.1.0 on 2025-03-02 and 2024.4.1 on 2024-12-31, and the last push to the default branch, dev, was on 2026-09-21.

The repository also carries README translations in Russian and Simplified Chinese, which is a reasonable signal that the audience is not only English speaking.

## The connector list is the actual feature

The README states that DataCap can query data from any SQL-speaking datastore or data engine, and then shows the connectors, which is the most informative part of the documentation.

The analytical engines include ClickHouse, Presto, Trino, Hive, Kyuubi, Druid, Kylin, Impala, Phoenix, Apache Doris, StarRocks, Pinot, Dremio and Spark-adjacent stores. The transactional set covers MySQL, PostgreSQL, Oracle, SQL Server, IBM DB2, DaMeng, H2, MonetDB, CrateDB, OceanBase, Snowflake, DuckDB, YDB and others. The NoSQL and streaming side adds MongoDB, Neo4j, Redis, Kafka and ZooKeeper. The time series family is there too, with TDengine, IoTDB, GreptimeDB, QuestDB and CeresDB. Storage and object systems include Apache HDFS and Aliyun OSS, and Cassandra and Hive sit alongside.

The size of that list is a double-edged fact. A wide connector surface means you can point one tool at a heterogeneous estate without writing per-database clients. It also means the maintenance burden of tracking upstream dialects and client library changes across dozens of projects, and the README shows the connectors as individual assets under docs/assets/plugin, which suggests they are maintained as separate pieces rather than folded into one module.

## The module layout tells you the architecture

The top-level entries are the clearest description of the system, because each directory names a responsibility.

There is core/ for the server itself, client/ for the user interface, plugin/ for the connectors, driver/ for the per-database client layer, parser/ for turning SQL into an internal representation, convert/ for the transformation and conversion operations, executor/ for running queries, scheduler/ for scheduling them, fs/ for file handling, notify/ for notifications, lib/ for shared code and shaded/ for packaging dependencies so the server can ship as one artifact.

On top of that sit design/ for the user interface assets, test/ for the test suite, a Dockerfile and docker-compose.yml at the root, a configure/ directory holding the git hooks, the schema and the application properties, and docs/.

The build is Maven, with a pom.xml at the root and the wrapper scripts mvnw and mvnw.cmd plus a .mvn/ directory, and there is a .java-version file that pins the expected JDK. The server image is built from a Java 11 base, so the project is still on the older long-term-support release rather than a newer one.

## Running it with Docker Compose

The compose file gives you a full three-service stack: MySQL for the application's own metadata, ClickHouse as a data source to query, and the DataCap server itself.

```yaml
services:
  app-mysql:
    image: mysql:latest
    environment:
      MYSQL_ROOT_PASSWORD: 12345678
      MYSQL_DATABASE: datacap
    ports:
      - "13306:3306"
    volumes:
      - ./configure/schema/datacap.sql:/docker-entrypoint-initdb.d/schema.sql
```

Two details are worth noticing. The schema file is mounted into the MySQL container's initdb directory, so the application tables are created on first start of the volume, and the host port is 13306 rather than 3306, which avoids clashing with a MySQL you may already run locally.

The ClickHouse service runs the official ClickHouse server image with a datacap database and a default user, and the DataCap service itself depends on both. Its port mapping is 9099 on the host to 9096 in the container, the application properties file from configure/docker/application.properties is mounted into the image, and a named volume keeps the data directory.

The compose file declares four named volumes, for MySQL data, ClickHouse data, ClickHouse logs and the DataCap data directory, so the stack persists across restarts without mixing state between runs.

## The server image and its entry point

The Dockerfile is short and tells you about the packaging. It builds on eclipse-temurin:11-jdk-focal, adds a tarball named datacap-server-*.tar.gz from the dist directory, unpacks it into /opt/app and renames the extracted directory to datacap. The working directory is then /opt/app/datacap and port 9096 is exposed.

The entry point is worth a second look:

```dockerfile
ENTRYPOINT ["sh", "./bin/debug.sh"]
```

A script named debug.sh is the container entry point. That is the sort of detail that matters when you run the image, because the container starts in whatever mode that script sets up rather than in a separately tuned production profile, and the image tag used by the compose file is devliveorg/datacap:latest, a floating tag rather than a versioned one.

For a project that publishes versioned releases, using latest in the compose file means the version you run is not the version the release notes describe. Pinning the tag is a one-line change and worth doing before you rely on the stack.

## Default accounts and the required git hook step

The README publishes two default accounts, one named datacap with the password 123456789 and one named admin with the password 12345678. They are printed in the README as the way to sign in after starting the application.

That is convenient for a first run and a poor default for anything else, since these are the credentials an internet-exposed instance would start with. If you deploy DataCap anywhere beyond a laptop, changing them is the first task, and the compose file's MySQL root password is set to the same weak value, so the metadata database starts in a similar state.

The README also marks one step as must-read for users, to be executed after cloning the code locally:

```bash
cp configure/git-hook/* .git/hooks
chmod 700 .git/hooks/*
```

That installs the repository's own git hooks, which the project expects contributors to have. It is a contributor setup step rather than a runtime one, but it is presented in the same breath as the requirements, which is the kind of thing worth understanding before you wonder why a commit is being rejected.

## Where it sits against the alternatives

There are two ways to get the same result, and they suit different situations.

The first is to build the integration yourself: a thin service that holds a connection per datastore, parses queries, and renders them through a charting library. For two or three well-understood databases this is often less work than adopting a platform, and you keep full control of what the interface does. It also means every new engine is a project.

The second is a general analytics product with connectors for many sources. DataCap takes that position, with a connector catalogue that spans engines, transactional stores, document and graph databases, streams and time series databases, and it adds the transformation and monitoring features that the README describes.

The trade-off is that a broad connector surface has to be maintained against upstream change, and the release history shows a project on a cadence of one or two releases per year, with 2025.1.1 the most recent published release and work continuing on the dev branch afterwards. For an evaluation, the questions to answer are practical: does the connector for your specific engine work with your version of it, does the transformation layer do what you need or only what the platform offers, and who maintains the connector when the upstream database changes.

## Conclusion

DataCap suits an organisation whose data is spread across several engines and that wants one query and charting surface instead of a client per database, and it suits teams willing to run the server themselves under Apache-2.0. It is the wrong choice if you have two well-understood databases, since a thin service of your own is smaller and easier to own. Verify first that the connector for your exact engine works against your version of it, that the published image tag you pin matches the release you tested, and that you have changed the documented default accounts before the instance is reachable by anyone but you.

## FAQ

### What databases can DataCap query?

Any SQL-speaking datastore or data engine, with connectors listed for ClickHouse, MySQL, Presto, Trino, PostgreSQL, Hive, Druid, MongoDB, Neo4j, Kafka, Redis, Snowflake, DuckDB, TDengine, IoTDB and many more. The list also includes time series and object storage systems.

### How do I start DataCap with Docker Compose?

The compose file starts MySQL on host port 13306, ClickHouse on 8123 and the DataCap server mapped to 9099 on the host and 9096 in the container. The application schema is mounted into the MySQL init directory, and the server configuration comes from configure/docker/application.properties.

### What are the default sign-in credentials?

The README lists two accounts, datacap with the password 123456789 and admin with the password 12345678. They exist so you can sign in after a fresh start, and they should be changed before the instance is reachable by anything else.

### Which Java version does the server need?

The Dockerfile builds the server image from eclipse-temurin:11-jdk-focal and the repository carries a .java-version file. The published release tags are dated by year, with 2025.1.1 released on 2025-07-28.

## Sources

- [devlive-community/metaforge on GitHub](https://github.com/devlive-community/metaforge)
- [License: Apache-2.0](https://github.com/devlive-community/metaforge/blob/dev/LICENSE)
- [Project website](https://datacap.devlive.org/)
- [README](https://github.com/devlive-community/metaforge/blob/dev/README.md)
- [Releases](https://github.com/devlive-community/metaforge/releases)

---

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