Routing APIs Compared: Choosing the Right Shortest-Path Service
In my previous post on pgRouting, I showed how to run shortest-path queries directly inside PostgreSQL. That approach works well when your road data is already in Postgres and your network is moderate-sized. But what happens when you need live traffic data, global coverage, or routing at thousands of queries per second? That is where external routing APIs and dedicated routing engines come in.
I have evaluated five routing services that cover the spectrum from fully managed APIs to self-hosted open-source engines. Each one makes different trade-offs around cost, speed, customization, and data freshness. Here is what I found.
Google Routes API
The Google Routes API is Google’s current routing service, replacing the legacy Directions API. According to Google’s documentation, it computes optimal routes between locations using proprietary algorithms and Google’s own road network data, incorporating real-time traffic and historical patterns. It supports driving, walking, cycling, transit, and two-wheeled vehicle modes.
The Routes API adds features not available in the older Directions API, including eco-friendly route options, toll fee calculations, and traffic-aware polylines. You do not get to see or modify the underlying graph, which means you get traffic-aware results but no control over cost functions or road weighting.
Pricing is per request. Check the Google Routes pricing page for current rates.
Mapbox Directions API
According to the Mapbox Directions documentation, the API is built on open-source routing engines (OSRM and Valhalla, depending on the profile). It supports driving, walking, and cycling profiles with optional real-time traffic on driving routes.
Mapbox offers features like GPS trace snapping, route annotations with per-leg speed and congestion data, and profile customization through the Mapbox platform. The underlying data comes from OpenStreetMap, supplemented by Mapbox’s own telemetry. For teams already using Mapbox for maps or geocoding, adding Directions keeps the stack consolidated.
OpenRouteService
OpenRouteService (ORS) is an open-source routing API maintained by the Heidelberg University Institute for Geoinformation Technology. According to the ORS documentation, it supports driving, walking, cycling, and wheelchair profiles, and it runs entirely on OpenStreetMap data.
ORS focuses on customization. The docs describe support for custom routing profiles with specific vehicle dimensions, weight limits, and road avoidance criteria. The public API has rate limits, but you can self-host ORS with your own OSM data. Check the ORS API documentation for current rate limit details.
I recommend ORS for teams that need specialized vehicle profiles or accessibility routing and want to stay within the open-source ecosystem.
OSRM
OSRM (Open Source Routing Machine) is an open-source routing engine that prioritizes query speed. According to the OSRM documentation, it preprocesses the road network using contraction hierarchies, a technique that shortcuts through intermediate nodes to reduce graph size.
The preprocessing step is the trade-off. OSRM compiles the road graph into an optimized format before serving queries, which means you cannot change edge weights at query time the way you can with pgRouting. If your cost function is static (distance or average travel time), OSRM handles it well. If you need dynamic costs, look elsewhere.
OSRM is self-hosted only. There is no managed API. You download an OSM extract, run the preprocessing pipeline, and serve queries via an HTTP API.
Valhalla
Valhalla is an open-source routing engine originally developed at Mapbox and now maintained as an independent project. According to the Valhalla docs, it uses a tiled, hierarchical approach with a modified A* algorithm.
Where Valhalla differs from OSRM is in dynamic costing. The Valhalla documentation describes support for adjusting speed factors, road penalties, and avoidance criteria per request without reprocessing the graph. It also lists time-dependent routing (different speeds by time of day), isochrone generation (reachability maps), and map matching as supported features.
Like OSRM, Valhalla is self-hosted. Mapbox runs Valhalla behind their Directions API, and the open-source version is available separately.
Comparison
| Feature | Google Routes | Mapbox | OpenRouteService | OSRM | Valhalla |
|---|---|---|---|---|---|
| Self-hostable | No | No | Yes | Yes | Yes |
| Live traffic | Yes | Yes (driving) | No | No | No |
| Custom cost functions | No | Limited | Yes | No (static) | Yes (dynamic) |
| Preprocessing required | N/A | N/A | Yes | Yes (heavy) | Yes (lighter) |
| Free tier | See pricing page | See pricing page | See docs | Unlimited (self-host) | Unlimited (self-host) |
When to Use an API vs pgRouting
I recommend pgRouting when your spatial data is already in Postgres, you need custom cost functions that reference other database columns (elevation, road condition, time-of-day tolls), or you want no external dependencies. pgRouting does not require preprocessing, which makes it straightforward for moderate-sized networks.
A managed API (Google, Mapbox, or ORS public) makes sense when you need live traffic, global coverage without maintaining your own OSM data, or when routing is a small feature in a larger application and you do not want to operate additional infrastructure.
A self-hosted engine (OSRM or Valhalla) is worth evaluating when you want to avoid per-query costs and can manage the hosting. OSRM focuses on static cost routing with fast query times. Valhalla supports dynamic costing, isochrones, and time-dependent routing according to its documentation.
For many teams, the answer is a combination. pgRouting works well for ad hoc analysis and custom graph queries in the database, while OSRM or Valhalla can serve user-facing routes in a production application.
