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.

Install with pip install rustnx (Python 3.10 or newer, including free-threaded 3.14t; prebuilt for Linux, macOS and Windows).

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 in functions that treat parallel edges specially, or callable weights, keeps running in NetworkX, so turning it on never breaks working code.

When rustnx helps, and when it doesn't

A NetworkX graph is a dict of dicts in Python, so rustnx first copies it into a compact Rust layout. NetworkX caches the copy on the graph, and later calls reuse it until the graph changes.

Conversion costs about as much as reading the graph once in Python, which is the floor for anything that starts from a NetworkX graph. So:

• Heavy algorithms win right away. Betweenness, closeness, PageRank, distance measures, clustering and the centralities take seconds to minutes in NetworkX and a fraction of a second here, conversion included.
• Cheap algorithms win when repeated. A single BFS or Dijkstra on a big graph costs about the same as one conversion, so the first call is not much faster; the following calls on the same graph are.
• Small graphs stay in NetworkX. Below 500 nodes, linear-time functions run in NetworkX automatically, since converting would cost more than it saves. You can still force rustnx with backend="rustnx".
• Big Python results limit the gain. Functions that return a path for every node (single_source_shortest_path, all_pairs_shortest_path, all_shortest_paths) or a new graph (k_core, bfs_tree) spend most of their time building Python objects, so they speed up 2–8× rather than 50×.
• Some inputs run in NetworkX: unsupported functions or parameters, callable weights, multigraphs in functions that treat parallel edges specially, graphs whose weights mix ints and floats in functions that return lengths, and graph subclasses that override how they are read. The results are still correct; they're just not faster.

To skip conversion entirely, build the graph in Rust (next section).

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

The full list, with every parameter rustnx handles and what falls back to NetworkX, is in docs/API.md.

Multigraphs

MultiGraph and MultiDiGraph run in Rust for the functions whose NetworkX code sees a multigraph only through its neighbors and, for weights, the minimum over parallel edges: components, traversals, the shortest path family, betweenness, closeness and harmonic centrality, the distance measures, and is_bipartite. Other functions (for example pagerank, which sums parallel weights, or degree-based ones) run in NetworkX.

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.

See CONTRIBUTING.md for the rules and how to add an algorithm, and SECURITY.md for reporting security problems.

Roadmap

• More algorithms: see the todo table in CLAUDE.md.
• Multigraph support for the remaining functions (pagerank, degree-based ones).

License

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