NetworkX: a Python graph library with no required dependencies

What NetworkX is for, and who actually needs it

NetworkX is a Python package for the creation, manipulation and study of the structure, dynamics and functions of complex networks, according to its README. That sentence covers a wide range, so it is worth being concrete. The library gives you graph objects, a large catalogue of algorithms that operate on them, and generators for standard graph families. The audience is developers and researchers who already work in Python and want graph structure to behave like any other data structure in their code.

It is not a service. There is no daemon to start, no port to open and no query language to learn. The pyproject.toml lists an empty dependencies array, so a plain install pulls in nothing beyond the standard library. That single fact explains a lot about where NetworkX fits: it can be dropped into a locked-down environment, a teaching notebook or a CI job without dragging a dependency tree behind it.

The project sits in the scientific Python orbit. The README points to a Scientific Python Discord and to an open meetings calendar, and the classifier list includes Scientific/Engineering categories for Bio-Informatics, Information Analysis, Mathematics and Physics. If your problem is a network of interactions and your tool of choice is a Python interpreter, this is the library that assumes exactly that.

How NetworkX represents a graph and moves data through it

The core object is the graph itself, and the README example shows the shape of the API. You create a Graph, add edges with attributes, then call a function that takes the graph as its first argument. In the README's four-edge example, each edge carries a weight attribute, and shortest_path is asked to use it by name: weight="weight". The library does not assume a numeric weight is stored in a fixed slot; you name the attribute you want the algorithm to read.

That design repeats across the package. Algorithms are free functions rather than methods, so they compose with ordinary Python and with each other. Attributes ride along on nodes and edges as dictionaries, which means you can attach whatever domain data you have without changing the graph type.

Graphs are in-memory Python objects. There is no storage layer described in the README, and no client-server split. The repository layout reflects this: the networkx/ package holds the implementation, doc/ holds documentation, examples/ holds runnable scripts grouped by topic, and benchmarks/ holds performance work. The examples directory is subdivided into basic, algorithms, drawing, graph, geospatial, 3d_drawing, graphviz_drawing, graphviz_layout and subclass, which is a fair map of what the library is expected to do.

The pyproject.toml also registers an entry point under networkx.backends called nx_loopback, pointing at networkx.classes.tests.dispatch_interface. That indicates a backend dispatch mechanism exists in the codebase, but the README does not describe it, so treat it as an internal hook rather than a documented extension point.

Installing NetworkX and running a first shortest path

The README gives two install commands. The plain one installs the library and nothing else, matching the empty dependencies list in pyproject.toml. The second pulls in the optional extras grouped under the default name, which is what you want if you plan to draw graphs or read and write extra formats.

pip install networkx

pip install networkx[default]

The README also links to an installation guide at networkx.org for further detail. Note the interpreter requirement from pyproject.toml: requires-python is ">=3.12,!=3.14.1", so an older Python will refuse the install rather than fail later at import time.

Once installed, the README's own example is the fastest way to confirm the package works. It builds a four-node undirected graph, attaches a weight to each edge, and asks for the shortest path from A to D.

import networkx as nx

G = nx.Graph()
G.add_edge("A", "B", weight=4)
G.add_edge("B", "D", weight=2)
G.add_edge("A", "C", weight=3)
G.add_edge("C", "D", weight=4)

print(nx.shortest_path(G, "A", "D", weight="weight"))

The output is ['A', 'B', 'D']. The direct-looking route through C costs more once the weights are summed, which is the point of passing weight="weight" rather than letting the function count hops. If you see that list, the install and the algorithm both work.

Where NetworkX stops being the right tool

The most common mismatch is treating NetworkX as a graph database. It is not one. Nothing in the README describes persistence, transactions, a query language, a server process or concurrent access from multiple clients. Your graph lives in the memory of one Python process and disappears when that process ends. If your graph is larger than the machine's RAM, or needs to be queried by several services at once, this is the wrong layer.

Performance is the second boundary. The package is pure Python with no required dependencies, which is a deliberate trade: portability and clarity in exchange for speed on very large graphs. The repository's benchmarks/ directory exists precisely because performance is a tracked concern rather than an afterthought, but the README makes no performance claims and none should be inferred.

There is also a version constraint worth reading twice. requires-python is ">=3.12,!=3.14.1", so the 3.14.1 patch release is explicitly excluded. If your environment is pinned to that exact interpreter, the install will not resolve, and the fix is to move to a different patch release rather than to work around the library.

Finally, NetworkX is a library, not an application. It will not visualise anything for you by default; drawing lives in the optional extras and in the examples/ drawing and graphviz directories. If what you want is a rendered diagram from a data file with no code, you are looking at the wrong kind of project.

NetworkX versus a graph database such as Neo4j

The comparison people actually search for is NetworkX against Neo4j, and the difference is architectural rather than a matter of degree. NetworkX is an in-process Python library: you import it, build objects, call functions, and the graph is a variable in your program. Neo4j is a database server with its own query language and storage engine; your program talks to it over a connection.

That changes what each is good at. With NetworkX, an algorithm is a function call and the data is already local, so iteration is fast and there is no schema to design. With a graph database, the graph outlives the process, multiple clients can query it, and traversal is pushed to the server. The cost is operational: something has to run and be maintained.

A practical pattern is to use both, with NetworkX on the analysis side. Pull a subgraph from the database, analyse it in Python, and write results back. The README does not document any Neo4j integration, so that pattern is something you would build yourself rather than a supported feature.

A second comparison that comes up is igraph, which is another graph library with a Python binding. The distinguishing fact here is the dependency stance: NetworkX declares no required dependencies, while a library with a compiled core necessarily brings one. That matters in constrained environments, and it is also the reason NetworkX is the easier of the two to read end to end when you want to understand an algorithm.

Maintenance, releases and what the BSD licence lets you do

The repository is not archived, and the last push was on 2026-09-18. The most recent release listed is networkx-3.7rc0 from 2026-09-17, a release candidate, with networkx-3.6.1 from 2025-12-08 and networkx-3.6 from 2025-11-24 as the preceding stable releases. The presence of a release candidate alongside a recent push indicates ongoing work, and the project describes itself in pyproject.toml as Development Status :: 5 - Production/Stable.

Upgrade cost is unusually low for a library of this scope, because there are no transitive dependencies to reconcile. The main upgrade constraint is the interpreter floor: requires-python is ">=3.12,!=3.14.1", and the classifier list covers 3.12 through 3.15. Moving to a new NetworkX release therefore mostly means moving your Python version, not auditing a dependency tree.

The licence is the 3-clause BSD licence, stated in both the README and pyproject.toml, with LICENSE.txt in the repository root and a copyright line reading "Copyright (c) 2004-2026, NetworkX Developers". The repository's licence field on the hosting side reports NOASSERTION, which is a metadata mismatch rather than a different licence: the files themselves say BSD-3-Clause. BSD-3-Clause is permissive and permits use in closed-source products, but the details of your situation are for your own legal review, not something this article can settle.

Governance is light-touch and public. The README lists a mailing list, GitHub Discussions, a Discord invite and an open meetings calendar, and CONTRIBUTING.rst and CODE_OF_CONDUCT.rst sit at the repository root.

Editorial conclusion

Adopt NetworkX when the graph fits in memory and the work is analysis, algorithm prototyping or teaching; it needs Python 3.12 or newer and installs with pip install networkx. Do not adopt it as a graph database, because the repository lists no persistence, server or query language. Before committing, verify your Python version against requires-python, check whether your algorithm is already covered in the algorithms examples directory, and confirm which optional extras you need if you plan to draw graphs.

Frequently asked questions

Official sources

1. Issues
2. networkx/networkx on GitHub
3. Project website
4. README
5. Releases