NebulaGraph and the split between storage and compute

Storage and computing separation is the deployment shape, not a feature bullet

The feature list opens with symmetrically distributed, storage and computing separation, horizontal scalability, and strong data consistency by RAFT protocol. The second of those decides the rest, because a separated storage tier and compute tier means you are not installing a database so much as assembling one. The project is introduced as a distributed graph database with multiple components, and the ways offered to obtain it are a download page, a build from source path, and an AWS cloud option.

What the file does not do is name those components, say how many nodes a working setup needs, or give a single command you can paste. So the same property that makes horizontal scaling possible is also the thing you must resolve first, and the minimum viable topology lives entirely in the documentation rather than in the repository.

OpenCypher compatibility is stated without a dialect list

The query language is described as OpenCypher-compatible. That is the right choice for a graph database, because it means Cypher already written against another engine has a fair chance of running here, and it is also the least specific line in the feature list. No OpenCypher version is named, no list of supported clauses or functions appears, and there is no statement about which Cypher extensions are out of scope.

The consequence lands on migration work rather than on evaluation. Compatibility tells you your existing syntax is a reasonable starting point, not that it will execute unchanged, and the distance between those two statements is documented somewhere other than here. If your application leans on a particular Cypher function or a particular MATCH pattern shape, verify that specific piece in the docs before committing to the port.

RAFT is offered as a guarantee with no knobs attached

Strong data consistency by RAFT protocol sits in the same short list as symmetrically distributed and horizontal scalability. Read together, those three say every node participates equally and writes are replicated through a consensus log, which is the design that lets one graph be split across machines without losing agreement about what has been committed.

The absence is in the configuration. No replica count, quorum setting, or consistency tuning parameter appears anywhere in the front page, so the consistency model reads as a fixed property of the system rather than something you choose per operation or per pool. If your workload needs to trade durability against write latency on an ingest-heavy pipeline, the knob is not described here, and you will be looking for it in conf/ and the docs.

Every documentation link is pinned to the 3.8.0 release

Look at the URLs and most of them carry the same version segment. The quick start, the build from source page, the FAQ, and the Ecosystem and tool version pages are all under docs.nebula-graph.io/3.8.0/. That means this page describes one specific release rather than the current state of master.

The release list makes that concrete. The most recent tags are v3.8.0 from 2024-05-17, v3.6.0 from 2023-08-11, and v3.5.0 from 2023-05-23, while the repository itself last took a push on 2026-09-08. Code is moving and the tags are not, so a reader following the quick start is being walked through 3.8.0 whether or not that matches the commit they built.

Three ways to get it, and not one command to copy

The full menu offered here is a download page, a build from source route, and an AWS cloud sign-in. There is no package manager line, no container invocation, no configure step, and nothing copyable into a terminal.

For a C++ codebase with a CMakeLists.txt at the root and a third-party/ directory beside it, building from source is a dependency resolution exercise rather than a one-liner, and no required library list is given. The practical reading is that this repository advertises the documentation rather than replacing it. Budget time for the install page instead of this file, and if you want an opinionated packaged deployment rather than a self-managed one, the cloud option is the only managed path named.

The release history and the roadmap sit inside a comment block

Two sections of this README are wrapped in an HTML comment, so they exist in the file and never render on the page. The first is a notice about repository history: NebulaGraph used to be split across three repositories, Nebula-Graph, Nebula-Storage and Nebula-Common, for versions between v2.0.0 and v2.5.x, and the codebase returned to a single mono-repo at v2.6.0. The second is a roadmap link.

That same hidden block carries the warning that NebulaGraph 1.x is not actively maintained and should be moved to 2.x, and that the data format, rpc protocols and clients are not compatible between the two. None of that reaches a visitor, so anyone arriving from an old 1.x deployment discovers the incompatibility by reading the comment or by finding the upgrade guide, not from the front page.

conf/, docker/ and udf/ say more than the feature list does

The top level carries .clang-format, .clang-tidy, a .linters/ directory, a Coding_Style_Guide.md and a .licenserc.yaml, sitting beside CMakeLists.txt, cmake/, src/, third-party/, tests/, docs/, docker/, conf/, package/, resources/, scripts/, udf/ and codecov.yml.

Two of those directories are worth noting beyond the feature list. conf/ is where a multi-component system is configured, which is the concrete counterpart to the storage and computing separation claim and the place to look for the settings the front page never mentions. udf/ sits in the tree, but the README does not describe it.

Editorial conclusion

NebulaGraph suits teams already planning a multi-component deployment who want Cypher syntax without giving up a distributed store. It does not suit a single-binary pilot, because the quick start, install, FAQ and Ecosystem links in the README point at 3.8.0 while master has moved since the 2024-05-17 tag. Before committing, confirm your OpenCypher queries against the docs rather than assuming compatibility, and read the how-to-contribute page the README links if you plan to contribute.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. vesoft-inc/nebula on GitHub