# pgRouting Review: PostgreSQL Routing and Network Analysis

> pgRouting is a C++ PostgreSQL extension that adds shortest-path routing and network analysis to PostGIS. It is suited to teams that want routing queries to run inside their spatial database, with PostgreSQL, PostGIS, C++17, Boost, and CMake as build prerequisites.

**pgRouting/pgrouting** — Repository contains pgRouting library. Development branch is "develop", stable branch is "master"

- Repository: https://github.com/pgRouting/pgrouting
- Website: https://pgrouting.org
- Stars: 1,440 · Forks: 402
- Language: C++
- License: GPL-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/pgrouting-pgrouting

## Why pgRouting belongs inside a spatial database

pgRouting solves a data-locality problem. It extends the PostGIS and PostgreSQL geospatial database with routing and other network-analysis functions, so network queries can run against tables managed by the same database. The intended users are PostgreSQL and PostGIS operators, spatial analysts, GIS developers, and applications that already keep roads, transit connections, or other networks in a database.

The repository identifies a broad algorithm set rather than a single route API. Its documented capabilities include All Pairs Shortest Path algorithms, A-star, bidirectional algorithms, several applications of Dijkstra algorithms, driving distance, Yen's algorithm, and Traveling Sales Person. It also mentions cost functions and queries with points, which indicates that the project is intended for more than a hardcoded shortest path between two coordinates.

This design is materially different from sending every request to a separate routing service. The README does not document a hosted API, a network client, or a separate service process. The repository layout supports a database extension model: C++ source under src, public headers under include, SQL files under sql, PostgreSQL build configuration in CMakeLists.txt, and tests under pgtap. That layout suggests that the main adoption decision is about fitting PostgreSQL's extension and dependency requirements, not about deploying another application server.

## The C++ extension and SQL query model

pgRouting is implemented primarily as a C++ library that is compiled into the PostgreSQL environment. The README states that pgRouting requires C++17. Its build requirements also include a C and C++ compiler, Perl, a supported PostgreSQL version, Boost Graph Library 1.74 or later, CMake 3.22 or later, and Sphinx for documentation builds in the range 4.0.0 up to but not including 7.0.

The extension model means the routing algorithm is available through the database rather than through a standalone desktop program. The repository's sql directory is the natural location for SQL-facing definitions, while src and include contain the compiled implementation. The README does not give a complete function catalog or a complete query example, so it would be misleading to claim a particular signature, return column, or edge-model rule without consulting the versioned documentation.

The algorithm selection is more important than the presence of a generic route command. Dijkstra variants address shortest paths and driving distance. A-star is included as a separate algorithm. Bidirectional search is listed independently, while Yen's algorithm and Traveling Sales Person cover route sets and tour-oriented problems. The actual SQL function name and parameters should be checked against the online documentation for the installed pgRouting release.

## Building pgRouting and creating the extension

The README documents compilation through a separate build directory. For Linux, the documented sequence creates a build directory, changes into it, configures the project with CMake, builds it, and installs it. The reader should expect a configured build tree and an installed PostgreSQL extension before the SQL command can be used.

```bash
mkdir build
cd build
cmake ..
make
sudo make install
```

After the installation step, the README creates a database and enables the extension. `CASCADE` allows PostgreSQL to create required dependent extensions when needed, but the README separately identifies PostGIS as a user requirement. The reader should verify that PostGIS is available before attempting the extension command.

```bash
createdb mydatabase
psql mydatabase -c "CREATE EXTENSION pgrouting CASCADE"
```

For MinGW on Windows, the documented commands use the `MSYS Makefiles` generator and the same basic configure, build, and install sequence. The README also points to pre-built Windows binaries from the PostGIS website. That gives Windows users a separate acquisition path, but the README does not document binary compatibility details or the installation location, so those should be checked before selecting that route.

## Choosing pgRouting for network-analysis workloads

pgRouting is most relevant when the network is already represented in PostgreSQL and the application benefits from keeping query inputs and results in SQL. It is less suitable for a team that wants a turnkey mobile navigation client, a browser routing engine, or a service with no PostgreSQL infrastructure. The README gives no such client, API, or deployment interface, so those uses cannot be inferred from the project description.

The listed feature set also creates a meaningful choice among algorithms. A simple shortest-path investigation may fit one of the Dijkstra variants. A-star is available when its search model matches the problem. Driving distance and point-based queries serve different analysis needs, and Yen's algorithm is relevant when alternative routes matter. TSP is a different problem class from point-to-point routing, so adopting pgRouting should not be framed as adopting one universal routing mode.

A real limitation is dependency weight. The README requires a supported PostgreSQL version and excludes versions 13 and earlier. It also requires PostGIS, Boost Graph Library 1.74 or later, CMake 3.22 or later, and C++17. The documentation does not state whether the current extension can be installed through a package manager in the reader's environment, and it does not provide a rollback procedure. Teams that cannot meet these build or runtime conditions will have limited adoption choices.

## Release maintenance, licensing, and upgrade boundaries

The repository is not archived, and its last push was on 2026-10-09. Recent releases listed for the project include v4.0.2 on 2026-09-05, v4.0.1 on 2026-01-31, and v4.0.0 on 2025-11-07. The README distinguishes the `develop` branch as development for the next minor or major release and says the `main` branch contains development for the next micro release. Repository metadata separately identifies `master` as the stable branch, so branch selection should be confirmed against the release being deployed.

Licensing is mixed at the file level. Most features are identified as available under `GPL-2.0-or-later`. Some Boost extensions are available under the Boost license, and code contributed by iMaptools.com is available under the MIT-X license. The presence of separate license files, including `BOOST_LICENSE_1_0.txt` and `LICENSE`, means a deployment review should account for the applicable component rather than treating the entire repository as one undifferentiated license. This is a licensing inventory point, not legal advice.

The repository includes release notes, `NEWS`, `NEWS.md`, documentation directories, and test directories. That supports an upgrade process, but the README does not document a migration command or rollback procedure. The release notes and versioned online documentation are the appropriate places to check SQL changes before replacing an installed extension.

## How pgRouting differs from a standalone routing library

pgRouting's defining choice is where computation and data meet. A standalone routing library can be embedded in an application that reads network data from files or services. pgRouting instead targets PostgreSQL and PostGIS, which can keep the network and the query process in the same database environment. That difference can reduce the amount of application-specific data plumbing, although the README does not quantify its performance or operational effect.

The trade-off is operational coupling. A standalone application may be easier to isolate from a database server, while pgRouting requires compatible PostgreSQL, PostGIS, C++17, Boost, and CMake components. pgRouting also gains database-specific query composition, but the repository does not promise that every routing algorithm has the same interface or that all network models behave identically.

For an existing PostGIS deployment, this SQL-centered approach is the clearest reason to consider pgRouting. For a new service with no database, the same extension model can add unnecessary installation complexity. Compare the project's actual PostgreSQL integration requirements against the deployment and data-access needs of a standalone routing library.

## Conclusion

Adopt pgRouting when PostgreSQL and PostGIS already form the data layer and routing results must be queried through SQL. Do not choose it without checking its PostgreSQL, PostGIS, Boost, CMake, and C++17 requirements, or when a lightweight standalone routing client would be a better fit. The first project-specific check is whether the required extension can be built or installed for the target PostgreSQL environment.

## FAQ

### What is pgRouting used for?

pgRouting extends PostgreSQL and PostGIS with geospatial routing and network-analysis functionality. The documented features include Dijkstra applications, A-star, bidirectional algorithms, driving distance, Yen's algorithm, and TSP.

### How do I install pgRouting?

The README documents compiling pgRouting with CMake and installing it on Linux. After installation, it shows creating a database and running `CREATE EXTENSION pgrouting CASCADE`. PostGIS is listed as a user requirement.

### Does pgRouting support PostgreSQL 13?

No. The README states that pgRouting does not support PostgreSQL version 13 and earlier. It requires a PostgreSQL version supported by PostgreSQL's versioning policy.

### What license applies to pgRouting?

The README says most features are available under `GPL-2.0-or-later`. Some Boost extensions are available under the Boost license, and code contributed by iMaptools.com is available under the MIT-X license.

## Sources

- [License: GPL-2.0](https://github.com/pgRouting/pgrouting/blob/develop/LICENSE)
- [pgRouting/pgrouting on GitHub](https://github.com/pgRouting/pgrouting)
- [Project website](https://pgrouting.org)
- [README](https://github.com/pgRouting/pgrouting/blob/develop/README.md)
- [Releases](https://github.com/pgRouting/pgrouting/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pgrouting-pgrouting