cuGraph: NetworkX-shaped graph algorithms that run on the GPU

A whole repository is several libraries wearing one name

The most useful thing the README does is draw the package boundaries, because cuGraph is not one library. The table of contents lists cuGraph Python, pylibcugraph, and libcugraph with its C and C++ surfaces, plus nx-cugraph as a separate project, and each of those has its own readme page under `readme_pages/`.

The division is stated directly in the README's Python paragraph. The high-level cugraph Python API is the easy, familiar interface consistent with other RAPIDS libraries. Some use cases need lower-level graph theory concepts, so there is an additional Python API called pylibcugraph, intended for applications requiring tighter integration at the Python layer with fewer dependencies. Users who know C, C++ and CUDA can go to libcugraph and libcugraph_c for low level integration outside of Python entirely.

So there are three altitudes. Data scientists use the top. Python programmers who need control without a heavy dependency stack use the middle. Systems programmers embedding graph primitives link the bottom. The repository language on GitHub is CUDA, which matches the bottom layer being where the actual work happens.

The metadata frames the scale: 2239 stars, 369 forks, 131 open issues, Apache-2.0, last pushed 2026-09-21, with releases recorded in April, June and August 2026. Documentation lives at docs.rapids.ai rather than in the repository, and the README links separate nightly and stable API docs for Python, C and C++.

Why the NetworkX-shaped API is the whole adoption strategy

The README states the goal plainly: users familiar with NetworkX will quickly recognize the NetworkX-like API provided in cuGraph, with the goal to allow existing code to be ported with minimal effort into RAPIDS. Data scientists familiar with cuDF will pick up the Pandas-like API. That is the pitch, and it is more than marketing, because the alternative is learning a graph library whose object model differs from everything else in your stack.

There is a second route to the same algorithms, and it is worth knowing about if you already depend on NetworkX. nx-cugraph is a NetworkX backend, listed in the projects-that-use-cuGraph section as NetworkX via the nx-cugraph backend, with its own site at rapids.ai/nx-cugraph. That lets code written against NetworkX run on the GPU by changing the backend rather than rewriting algorithm calls, which is a much smaller change than migrating to the cuGraph API.

The projects that depend on cuGraph give a sense of where it actually lands in production. The list includes ArangoDB, a native multi-model database, Memgraph, an in-memory graph database, PyGraphistry for GPU graph ETL and visualization, CuPy, and ScanPy, the single-cell gene expression toolkit. That last one is the most telling: ScanPy running on cuGraph means biological analysis pipelines where the graph step sits between heavy data stages and the data cannot afford a round trip to host memory.

PageRank from a CSV of edge pairs

The README's worked example is the clearest statement of the design, because it never leaves the GPU. Read the edge list into a cuDF DataFrame, construct a Graph from the source and destination columns, call PageRank, sort the result.

import cudf
import cugraph

# read data into a cuDF DataFrame using read_csv
gdf = cudf.read_csv("graph_data.csv", names=["src", "dst"], dtype=["int32", "int32"])

# We now have data as edge pairs
# create a Graph using the source (src) and destination (dst) vertex pairs
G = cugraph.Graph()
G.from_cudf_edgelist(gdf, source='src', destination='dst')

# Let's now get the PageRank score of each vertex by calling cugraph.pagerank
df_page = cugraph.pagerank(G)

Three details are worth slowing down on. The `dtype` argument pins the vertex identifiers to `int32` rather than letting inference choose, which matters on a GPU where the index width affects both memory footprint and kernel selection. `from_cudf_edgelist` takes column names as strings, so the Graph construction is a wrapper over your dataframe rather than a separate copy you have to keep in sync. And the return value is a DataFrame, so the result feeds straight into cuDF operations rather than needing conversion.

The README also notes that cuGraph supports data found in Pandas DataFrames, NetworkX Graph Objects and several other formats. That is the compatibility layer, and it is also the point at which you pay a device transfer.

cuDF, cuML and the argument for staying on the device

The RAPIDS section of the README makes the larger claim: the suite aims to enable execution of end-to-end data science and analytics pipelines entirely on GPUs, relying on NVIDIA CUDA primitives for low level compute optimization while exposing that parallelism and high-bandwidth memory speed through user-friendly Python interfaces.

The Apache Arrow on GPU subsection names the mechanism. The GPU version of Apache Arrow is a common API that enables efficient interchange of tabular data between processes running on the GPU, and end-to-end computation on the device avoids copying and converting data off it, reducing compute time and cost. This is the whole architectural argument in one paragraph: the win comes from not moving data, not from any single algorithm being faster in isolation.

The practical reading is that cuGraph is most valuable next to other RAPIDS components. The README describes cuGraph operating on cuDF GPU DataFrames so data can pass between ETL tasks in cuDF and machine learning tasks in cuML. If your workflow is Pandas, scikit-learn and NetworkX with a GPU bolted onto one step, each boundary crossing costs more than the algorithm saves. If your workflow is already cuDF to cuML with a graph step in between, cuGraph removes a bottleneck rather than adding one.

Version pinning and where the algorithm list lives

Two version facts are worth pinning down. The repository tree carries a `RAPIDS_BRANCH` file and a `VERSION` file, plus `dependencies.yaml`, which is the RAPIDS convention: libraries in the suite are versioned and branched together so a cuGraph build matches the cuDF and cuML builds it will exchange data with. The README also carries a note that for the latest stable README you should be on the latest branch, which is the usual consequence of that arrangement.

Algorithm coverage is not something this README will answer. It links a current list of algorithms on docs.rapids.ai, and that link is the one to open before designing anything, because not every algorithm supports every input type and the GPU path is not available for all of them. The tree gives the shape of the engineering effort: `cpp/` for the C++ and CUDA sources, `python/` for the Python layer, `cmake/` and `thirdparty/` for the native build, `benchmarks/` and `notebooks/` for performance work and examples, `mg_utils/` for MultiGraph support, `datasets/` for sample data, and `ci/` plus `scripts/` for the build pipeline.

Lint and format configuration is minimal and modern. `pyproject.toml` configures ruff with an 88 character line length, ignoring E203 and exempting `__init__.py`, with notebooks exempted from unused-import and unused-variable checks. The build itself goes through `build.sh` with a CMake layer, and `print_env.sh` exists to dump the environment.

Editorial conclusion

cuGraph earns its place in a pipeline only if the graph work is genuinely on the critical path and the data is already on the GPU. The reason is structural rather than incidental: cuGraph operates on cuDF GPU DataFrames so that edge lists never have to leave the device between the ETL stage, the algorithm and the model fitting stage, and the surrounding RAPIDS libraries assume the same thing. If your graph lives in a Pandas DataFrame or a NetworkX object, cuGraph will read it, but you will be paying for the transfer and you will get back a DataFrame, not a result you can keep in host memory cheaply. The API choice is the other thing that makes adoption cheap, since the Python layer deliberately mirrors NetworkX and the C layer mirrors C graph theory, so porting is mostly a matter of changing imports. Read the algorithm list on docs.rapids.ai before committing, because coverage varies by algorithm and by whether the graph is small enough for one GPU.

Frequently asked questions

Official sources

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