GeaFlow: a streaming graph engine whose pitch is incremental computation, and whose benchmarks admit a loss

A graph as the data model, from Ant Group into the Apache ecosystem

Apache GeaFlow is a distributed streaming graph computing engine originally initiated by Ant Group, and it has since been integrated into the Apache ecosystem. It is still marked as incubating, and the release tags say so explicitly, with v0.7.0 named V0.7.0 (Incubating).

The data model is the differentiator. The README states that GeaFlow uses a graph as its data model, with a vertex-edge storage format, and lists the core capabilities as trillion-level graph storage, hybrid graph and table processing, real-time graph computing and interactive graph analysis. The scenarios named are data warehouse acceleration, financial risk control, knowledge graph and social networks.

The rest of the feature list widens the scope rather than narrowing it: distributed streaming graph computing, hybrid graph and table processing expressed as SQL plus GQL, unified stream, batch and graph computing, interactive graph analytics, high availability with exactly once semantics, high-level API operator development, support for UDFs, graph algorithms and connectors, a one-stop graph development platform, and cloud-native deployment.

Two of those deserve attention. Hybrid graph and table processing is what makes it usable next to an existing warehouse rather than beside it, and unified stream, batch and graph computing is the claim that a team does not have to run two engines. There is a design paper, GeaFlow: A Graph Extended and Accelerated Dataflow System, published through the ACM Digital Library, and the documentation sits in docs/docs-en/source/ with a Chinese README alongside the English one.

Incremental computing is the mechanism, not a feature name

The performance section explains what the engine actually does differently, and it is the most important paragraph in the README.

GeaFlow supports incremental graph computing, allowing for continuous streaming incremental graph iterative computing or traversals on dynamic graphs, meaning graphs that are constantly changing. When GeaFlow consumes messages from real-time middleware, the points associated with the real-time data in the current window are activated, triggering iterative graph computing. In each iteration, only the updated points need to notify their neighbouring nodes, while unchanged points are not triggered for computing.

That is the whole argument. The engine keeps the graph resident, so an event touches a neighbourhood rather than invalidating the entire dataset.

The comparison the README draws is with the earlier industry approach, systems for distributed offline graph computing using Spark GraphX. To support similar engine capabilities, Spark relied on the Spark Streaming framework, and although that integrated approach can handle streaming consumption of point and edge data, it still requires full graph computation every time a calculation is triggered. The README calls this snapshot-based graph computing and says it makes it challenging to meet business performance expectations.

The WCC example, the weakly connected components algorithm, is the benchmark they chose, and the result is framed in terms of stability rather than peak speed. Since only the vertex and edge relations involved in the current window are activated, the computing time can be completed within seconds, and the computing time for each window remains fairly stable. As the data volume increases, Spark's need to backtrack through historical data during computing also grows, so while the machine capacity has not reached its limit, the computing delay shows a positive correlation with the data volume. Under similar conditions, GeaFlow's computing time may increase slightly but can generally still be kept at the level of seconds.

The benchmark where GeaFlow loses, and says so

The second performance section compares GeaFlow with traditional stream processing engines such as Flink and Storm, which are based on table models. The claim is that GeaFlow offers significant performance advantages in handling Join operations, especially for complex multi-hop relationships, like joins exceeding three hops and complex cycle searches.

The K-Hop algorithm is the test case. K-Hop relationships are chains in which individuals can know each other through K intermediaries, such as user relationships connected through K intermediaries in a social network, or a path of funds transferred consecutively K times in transaction analysis.

Then the README does something unusual and says that Flink performs slightly better than GeaFlow in one-hop and two-hop scenarios. The reason given is that the data volume involved in the Join calculations is relatively small in those cases, both the left and right tables are compact, and the traversal times are shorter. The README also notes that Flink's computing framework can cache the historical results of Join operations.

That paragraph is worth more than the chart next to it. A comparison that names its own losing case is telling you where the tool is not the answer, and the answer here is specific: shallow joins over compact tables are a table problem, and a table engine with a join cache handles them better. GeaFlow's case is the deep traversal, the cycle search and the continuously changing graph, where the alternative is to recompute everything.

Two ways to write the job: a GQL dialect or a Java API

GeaFlow supports two sets of programming interfaces, DSL and API, and the choice is the first real decision an adopter makes.

The DSL route is GeaFlow's SQL extension language, SQL plus ISO/GQL, with the application development documentation under docs/docs-en/source/5.application-development/2.dsl/. The quick start itself is written this way: the test job is a .sql file, loop_detection_file_demo.sql, submitted through a shell script.

The API route is the high-level API programming interface for developing applications in Java, documented alongside it. The feature list calls this high-level API operator development, and the repository layout supports it, since the project is Java with a root pom.xml and Maven modules, and the geaflow-ai/, geaflow-mcp/, geaflow-kubernetes-operator/ and geaflow-console/ directories suggest the platform is meant to be operated rather than merely run as a library.

For a team that already lives in SQL, the DSL is the shorter path and the quick start is written to be completed in an afternoon. For a team with existing Java domain logic and a need to unit test the operators, the API is the one to plan around. The two are not equivalent in expressiveness, and the documentation for each is separate, so this is a decision to make before writing the first job.

The quick start needs Git, JDK8, Maven and Docker

The README's quick start is unusually concrete, and it is a four step sequence for the jar and one more for the console.

The environment requirements are Git, JDK8, Maven and Docker. Then the code comes down, the project is packaged, and the example job is submitted:

git clone https://github.com/apache/geaflow.git geaflow

./build.sh --module=geaflow --output=package

./bin/gql_submit.sh --gql geaflow/geaflow-examples/gql/loop_detection_file_demo.sql

The console is a separate build that requires Docker to be running, and it is started as a container with a published port:

./build.sh --module=geaflow-console

docker run -d --name geaflow-console -p 8888:8888 geaflow-console:0.1

Note what the console step implies. This is a service that submits jobs and watches them, not a library, and the console image is pulled from tugraph/geaflow-console on Docker Hub.

The longer form of the quick start lives in the documentation, and the deeper detail is in the introduction document and the application development documents referenced from the README.

Where GeaFlow is the wrong choice

The first wrong fit is a shallow join workload. The README's own comparison says Flink is slightly better for one hop and two hop joins over compact tables, and that comparison is not about a corner case. If your work is a wide table join with caching and no deep traversal, a table oriented stream engine is the cheaper answer.

The second is a team that wants an established project. GeaFlow is incubating, at version 0.7.0, and the tags include a run of release candidates before it, which is a normal pattern for a young project and also a signal about its maturity. The last push to the repository was on 2026-10-12 and the repository is not archived, so the work continues, but a mature competing project has a longer production track record.

The third is a graph workload that is not continuous. The whole advantage is the incremental path, where an event activates a neighbourhood and the rest of the graph stays put. If your data arrives in daily batches and is recomputed wholesale, the incremental machinery buys nothing and you have taken on the complexity of a graph store for no benefit.

The fourth is a Java shop that wants a library rather than a platform. What is here is a distributed engine with a console, a Kubernetes operator, an AI directory and an MCP directory, and the quick start is a build of the whole project. That is the right shape for a data platform team and the wrong shape for a service that wants a graph query library.

The licence is Apache 2.0, with the LICENSE and NOTICE files at the root of the repository, and the usual Apache set of governance files alongside, GOVERNANCE.md, SECURITY.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md and a DISCLAIMER. Read the licence file for the terms that apply, and this is not legal advice.

Editorial conclusion

GeaFlow fits a team running continuous graph algorithms over changing data, such as risk control or knowledge graph work, where recomputing the whole graph on every event is the cost that hurts. It does not fit a workload whose joins are one or two hops, where the README's own comparison says Flink is faster, and it does not fit a team unwilling to run the Ant lineage stack with Docker. Before evaluating it, build the quick start package and run the loop detection example to see the shape of the GQL.

Frequently asked questions

Official sources

1. apache/geaflow on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases