TuGraph for OpenCypher graph storage, analytics, and procedures

TuGraph's labeled property graph target workload

TuGraph addresses applications in which records are meaningful mainly through their relationships. Instead of presenting every connection as a row assembled from foreign keys, its model is a labeled property graph with vertices, edges, labels, and properties. The README identifies lookup and graph analytics as its central problems, with particular emphasis on high data volume, low-latency lookup, fast bulk import, and support for datasets measured in tens of terabytes. These are project claims rather than independently reproduced results, so an adopter still needs workload-specific evaluation.

The intended users are engineers building relationship-heavy analytical or transactional applications, plus C++ or Python developers who need database-side procedures. TuGraph exposes OpenCypher for queries, serializable ACID transactions for consistency, primary, secondary, and full-text indexes for lookup paths, and an embedded graph computing framework for analytics. The repository also contains examples for Bolt, C++ RPC, DGL, DataX, multithreaded clients, Python, and procedures. That range suggests several client and integration paths, although the README does not document each demo's setup in enough detail to turn all of them into independent tutorials.

OpenCypher, indexes, transactions, and procedure execution

The clearest documented access path is OpenCypher. A client can formulate graph queries without TuGraph requiring the application to manually perform every neighbor lookup. The README does not provide a query example, parser grammar, or default database endpoint, so the exact syntax and connection sequence must come from the linked quick-start documentation. That omission matters for evaluation: knowing that an OpenCypher API exists does not establish whether a team's existing query set is fully covered.

TuGraph combines that query layer with a labeled property graph model and multiple index types. Full-text, primary, and secondary indexes serve distinct lookup needs, but the README does not explain their exact selection rules or update behavior. It also states that TuGraph provides full ACID support with serializable transactions. Serializability is the strictest part of that consistency description and is relevant when concurrent writes could otherwise produce ambiguous transaction ordering.

For computation that should execute close to stored data, the documented stored procedure interfaces use C++ or Python. The procedure mechanism is useful when a graph traversal must feed an application-specific algorithm without moving all intermediate results to the client. The repository includes a `ProcedureDemo`, but no procedure source or invocation sequence is included in the README. Based on the documented feature set, TuGraph offers four concrete layers: OpenCypher access, graph and property storage, index-assisted lookup, and embedded computation through analytics or stored procedures.

Docker and Linux source-build paths for TuGraph

The shortest documented installation path is a TuGraph runtime image from Docker Hub. The README names the image pattern as `tugraph/tugraph-runtime-[os]:[tugraph version]` and gives `tugraph/tugraph-runtime-centos7:4.5.1` as an example. It does not provide the command that downloads or starts that image, so this tutorial cannot safely invent a container name, port mapping, credential setup, or health check.

For a source installation, the README recommends Linux and offers Ubuntu and CentOS configuration values. The documented first build sequence clones the recursive repository, creates a build directory, configures CMake, compiles, and packages the result. Run it from the repository root:

$ git clone --recursive https://github.com/TuGraph-family/tugraph-db.git
$ cd tugraph-db
$ deps/build_deps.sh
$ mkdir build && cd build
$ cmake .. -DOURSYSTEM=centos7
$ make
$ make package

The `deps/build_deps.sh` step builds `tugraph-web` when that component is needed and may be skipped according to the README. For Ubuntu, the only documented difference is the `OURSYSTEM` value:

$ cmake .. -DOURSYSTEM=ubuntu

After `make package`, the README does not identify the package filename, startup command, default configuration file, or first query. Those are the first items to verify in `docs/en-US/source/3.quick-start/1.preparation.md`. The `tugraph/tugraph-compile-centos7` Docker environment is also listed as a build option, but no launch command accompanies it.

Release cadence and the cost of moving between TuGraph versions

The repository is not archived, and its last push was on 2026-05-11. The available release history lists `v4.5.2` on 2025-03-13, `v4.5.1` on 2024-12-04, and `v4.5.0` on 2024-09-14. These dates establish recent repository activity, but they do not by themselves describe compatibility guarantees or the effort required for each upgrade.

The README offers two development environments: `tugraph/tugraph-runtime-[os]:[tugraph version]` for running TuGraph and `tugraph/tugraph-compile-[os]:[compile version]` for compiling. Separating runtime and compilation images can help teams standardize environments, but the examples use different version conventions. The runtime example uses TuGraph version `4.5.1`, while the compile example uses `1.3.4`. That difference is visible in the documentation and should be resolved against the linked Docker environment definitions before relying on either image.

TuGraph uses the Apache-2.0 license. That permits use and modification under the license's conditions, but it does not by itself answer questions about bundled dependencies, container contents, trademark use, or distribution obligations. No legal interpretation is needed for this review. The practical upgrade check is concrete: compare the graph schema, indexes, stored procedures, client code, and image contents between the deployed version and the target release, because the README does not provide a migration or rollback procedure.

Where TuGraph is constrained, and what to choose instead

TuGraph is the wrong starting point when the application's primary abstraction is a fixed relational schema and ordinary table lookups. The documented feature set is centered on graph labels, edges, graph traversal, graph analytics, and relationship-heavy data. It does not present relational tables, SQL joins, or schema-oriented reporting as its main interface. This is not a claim that TuGraph cannot store properties. It is a statement about which model and query API the project documents.

The documentation is also thin at the operational boundary. The README does not give a verified startup command, default port, configuration-file path, backup procedure, restore command, rollback process, monitoring endpoint, or complete upgrade guide. The presence of ACID transactions does not supply any of those missing operational procedures. An engineer who needs those controls from the README alone will have to consult the separate documentation before estimating production work.

A real alternative path documented here is TuGraph's free trial on Aliyun rather than a local runtime or source build. That changes the deployment approach: the trial is hosted through the linked Compute Nest service, while the Docker and source-build paths leave environment setup and operation with the adopter. The README does not compare pricing, service limits, export procedures, or feature parity, so it cannot support a decision between those paths. The repository also lists OceanBase as a partner, but a partner listing is not documentation of a technical alternative or a product comparison.

Choosing between TuGraph deployment and evaluation routes

For a quick environment, the runtime image is the most direct option documented by the project because TuGraph already publishes an image family on Docker Hub. It avoids relying on the source compilation sequence, although it still leaves startup configuration unresolved in the README. The source build is more appropriate for engineers who need source access, need to produce a package, or require control over the Linux build configuration. The `tugraph/tugraph-compile-centos7` environment can serve that purpose according to the README, but its launch command is not included.

The Aliyun trial is a separate evaluation route with a different ownership boundary. Instead of creating and starting a local runtime, the project directs users to a hosted service and a separate quick-start guide. The README does not state whether the trial includes every storage, procedure, transaction, or analytics capability available in a self-managed release. Consequently, it should not be treated as proof of production feature parity.

Whichever route is chosen, the first meaningful verification should not be a generic health check. It should load a representative graph, create the full-text, primary, or secondary indexes required by the application, run the expected OpenCypher queries, and execute the intended C++ or Python procedures. The README's stated scale and throughput targets indicate why TuGraph deserves evaluation, but the first acceptance decision remains whether those documented capabilities operate correctly in the selected deployment environment.

Editorial conclusion

Application teams whose data model centers on connected entities should evaluate TuGraph when OpenCypher, ACID transactions, embedded graph analytics, and native procedures are concrete requirements. Operators who need a fully documented first query from the README, or evaluators who expect a direct comparison with another database, should first inspect the linked quick-start documentation. Before adoption, verify that the chosen release image or source build starts in the target environment, that the required graph workload performs as expected, and that the C++ or Python procedure interface matches the application architecture. The documented repository boundary is clear: TuGraph is positioned as a graph database, while the README does not document relational schema workflows or rollback procedures.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. TuGraph-family/tugraph-db on GitHub