rustnx

NetworkX, but fast. rustnx is a Rust-powered backend for NetworkX. You keep writing normal NetworkX code, and supported algorithms run in Rust instead of Python, often 50–100× faster.

import networkx as nx

nx.config.backend_priority = ["rustnx"]   # or: NETWORKX_BACKEND_PRIORITY=rustnx

G = nx.barabasi_albert_graph(4000, 4, seed=1)
nx.betweenness_centrality(G)              # runs in Rust: 0.4s instead of 41s

Nothing else changes. Anything rustnx doesn't support, such as other functions, multigraphs or callable weights, keeps running in NetworkX, so turning it on never breaks working code.

Native graphs: skip NetworkX entirely

For big graphs, build the graph in Rust directly. There's no conversion step, and it uses a fraction of the memory:

import networkx as nx
import rustnx

rustnx.enable()  # use rustnx where it can; everything else falls back to NetworkX

G = rustnx.DiGraph([("a", "b", 2.5), ("b", "c", 1), ("c", "a", {"weight": 4})])
nx.pagerank(G)                       # runs in Rust
nx.is_tree(G)                        # not in rustnx: converted to NetworkX automatically

G = rustnx.Graph.from_arrays(src, dst, weights)   # NumPy arrays; nodes 0..n-1

• The same results as NetworkX. Nodes come in order of first appearance, each node's neighbors in insertion order, and duplicate edges merge as add_edge would. So every algorithm returns what it would on a networkx.Graph built from the same edges.
• Read-only. It has nodes(), edges(data=True), neighbors, successors, predecessors, degree, has_edge, has_node and len. G.to_networkx() gives the full NetworkX API.
• Edge attributes must be numeric (or None). Graphs can be pickled.
• Call rustnx.enable() first. Without it, NetworkX raises NotImplementedError when a rustnx graph reaches a function rustnx doesn't implement, instead of converting it.

rustworkx-compatible API

The same Rust core also serves rustworkx's API:

import rustnx.rx as rx      # instead of: import rustworkx as rx

g = rx.PyDiGraph()
g.extend_from_weighted_edge_list([(0, 1, 2.0), (1, 2, 1.0), (2, 0, 4.0)])
rx.strongly_connected_components(g)
rx.dijkstra_shortest_path_lengths(g, 0, float)

• It behaves the same, not just the same names. PyGraph and PyDiGraph follow rustworkx's index model. Indices of removed nodes and edges are reused, most recently removed first. Graphs are multigraphs by default, and multigraph=False merges duplicate edges as rustworkx does. Neighbors are visited in petgraph's order, so order-dependent results (strongly_connected_components, topological_sort) match rustworkx exactly. Exceptions use rustworkx's names (NullGraph, DAGHasCycle, NoEdgeBetweenNodes, FailedToConverge and so on).
• It's tested against the real rustworkx. tests/test_rx_api.py applies random sequences of adds and removals to both libraries and compares every query and algorithm.
• Supported: the core graph-building, editing and query methods, plus betweenness_centrality, closeness_centrality, pagerank, dijkstra_shortest_path_lengths, all_pairs_dijkstra_path_lengths, the connected, strongly and weakly connected component functions, topological_sort, is_directed_acyclic_graph and networkx_converter. Not yet: subgraphs, compose, contraction, matrix and file I/O, and check_cycle=True.
• Speed: the algorithms are as fast as rustworkx's or faster (betweenness 1.8×, closeness 23×, strong components 2.5×). Building graphs is slower: the graph is stored in Python, so adding 500k edges takes 0.8 s, against rustworkx's 0.04 s.

Supported algorithms

Benchmarks

python benchmarks/bench.py on a 4-core machine (NetworkX 3.6.1):

The rustnx column is a repeat call. The first call on a graph also converts it to rustnx's format (about 0.15–0.25 s for a 1M-edge directed graph), and NetworkX caches that conversion on the graph. For the heavy algorithms conversion is negligible. For the linear-time ones, the first call is still faster than NetworkX, but by less.

Compared with other Rust backends

python benchmarks/compare.py runs the same calls through each installed backend and checks every result against NetworkX (same machine, NetworkX 3.6.1, rustworkx 0.18.1 via nx-rustworkx 0.2.1, franken-networkx 0.2.1). Times are repeat calls; the first call also includes conversion.

rustnx is also the fastest on first calls for all seven, because its conversion is about 5–20× quicker than nx-rustworkx's and 25–55× quicker than FrankenNetworkX's. It matches NetworkX's output, including order, for all seven.

On small graphs (under 500 nodes), the linear-time functions stay in NetworkX automatically, because the dispatch overhead outweighs the work. The centrality functions are faster in Rust at every size.

Correctness

Results must match NetworkX, or the speed is worthless. Two test layers check that:

1. tests/: about 1,400 randomized comparisons against NetworkX, run on directed and undirected graphs, int, float and missing weights, self-loops, and shuffled or non-integer node labels. They check values, dict ordering and error messages.

2. NetworkX's own test suite, with every supported call routed through rustnx:

   NETWORKX_TEST_BACKEND=rustnx NETWORKX_FALLBACK_TO_NX=True \
       pytest --pyargs networkx
   

   Result: 0 failures on NetworkX 3.4.2, 3.5 and 3.7 (9,066 tests passed on 3.7), with over 300,000 calls handled by rustnx. CI runs both layers on NetworkX 3.4, 3.5 and the latest release.

rustnx checks every call against the installed NetworkX's own signature. If a newer NetworkX adds a parameter, rustnx ignores it while it is left at its default. If the caller actually uses it, rustnx hands the call back to NetworkX.

Betweenness sums per-source contributions in parallel. It matches NetworkX to about 1e-15 relative error rather than bit-for-bit, and it gives the same result on any machine regardless of thread count.

How it works

nx.betweenness_centrality(G)
        │  NetworkX dispatch (backend_priority = ["rustnx"])
        ▼
rustnx.interface      convert G once: nodes → 0..n-1, adjacency → CSR arrays
        │             (NetworkX caches this on G for later calls)
        ▼
rustnx._core (Rust)   algorithm on flat arrays, GIL released, parallel via rayon
        │
        ▼
dict keyed by your original nodes, in NetworkX's order

Neighbor order in the Rust arrays follows NetworkX's adjacency dicts exactly. That's why traversal order, tie-breaking and result ordering all match.

Releasing

The Wheels workflow builds packages for Linux (x86-64, ARM), macOS (Intel, Apple Silicon) and Windows, plus a source package. It then installs each wheel on that platform and runs the test suite against it. The workflow runs on every pull request.

To publish a release:

1. One-time setup: on PyPI, add a trusted publisher for fabuseless/rustnx, workflow wheels.yml, environment pypi. Then create an environment named pypi in the repo's GitHub settings. No API token is needed.
2. Set the version in pyproject.toml and Cargo.toml, and move the changelog's Unreleased entries under the new version.
3. Push a tag such as v0.1.0a1. If every build and test passes, the workflow uploads the packages to PyPI.

Development

uv venv && source .venv/bin/activate
uv pip install maturin networkx pytest numpy scipy
maturin develop --release
pytest                                  # rustnx comparison tests
python benchmarks/bench.py --quick      # benchmarks

Layout:

• src/: Rust core. graph.rs handles conversion and CSR storage; algorithms/ holds the traversals and centrality.
• python/rustnx/: the NetworkX backend. interface.py is the entry point; algorithms.py holds the NetworkX-compatible wrappers.
• tests/: comparisons against NetworkX.
• benchmarks/: speed comparisons.

Roadmap

• More algorithms: bidirectional_dijkstra, weighted clustering.
• Multigraph support.

License

BSD 3-Clause, the same license as NetworkX. See LICENSE. Release notes are in CHANGELOG.md.