This is post 2 in our logistics and 3PL tech series. Post 1, the five engineering challenges every logistics platform hits, covers where this decision fits in the bigger picture. This post is the actual comparison: OSRM, Google Maps Platform, and Mapbox, and how to pick between them.
Every logistics feature, from a simple delivery ETA to full multi-stop route optimization, starts with a routing engine: something that turns a set of coordinates into a distance, a travel time, and a path. The three real options for a production logistics platform are self-hosted OSRM, Google Maps Platform, and Mapbox. They are not interchangeable. Picking the wrong one shows up months later as either a surprise cloud bill or a dispatcher who stops trusting the ETAs.
What does a routing engine actually need to do?
Strip away the branding and every routing engine answers three questions: what is the distance and travel time between two points (directions), what is the distance and travel time between every pair in a set of points (a distance matrix, the input to route optimization), and how do you turn many stops into an efficient order (optimization, sometimes bundled, sometimes not). Most engines expose these as three separate API calls or library functions. Understanding which one you need for a given feature keeps you from over-fetching, which is where routing costs balloon unnoticed.
What is OSRM and when does self-hosting make sense?
OSRM (Open Source Routing Machine) is an open-source routing engine that runs on OpenStreetMap data. You host it yourself, on your own infrastructure, and it has no per-request cost beyond your compute bill. For a platform routing thousands or tens of thousands of requests a day, that flat infrastructure cost beats per-request billing by a wide margin once volume crosses a threshold.
The tradeoff is that you now own a piece of infrastructure that was previously somebody else's problem. That means: keeping the underlying OpenStreetMap data current (stale data means routes through roads that have since closed or missed roads that have since opened), tuning the server for your query volume, and living with OpenStreetMap's accuracy, which is excellent in well-mapped regions like Western Europe and North American metros, and noticeably weaker in less-mapped rural areas and parts of the developing world. If your operation is regionally concentrated in a well-mapped area and you have the infrastructure capacity to run it, OSRM is very often the right long-term call. If your team does not want to own routing infrastructure, or your coverage area has patchy OpenStreetMap data, it is a harder sell.
What does Google Maps Platform get you that the others do not?
Google Maps Platform has the best real-world routing accuracy available, largely because it has the best live traffic data. For last-mile delivery, ride-hailing, or any use case where a five-minute ETA error is a customer complaint, that accuracy is hard to replicate elsewhere. It also has the deepest global map coverage, including regions where OpenStreetMap is thin.
The cost is real and it scales with usage in a way that surprises teams who model it late. Google bills per request across its Directions, Distance Matrix, and Routes APIs, and a logistics platform recomputing routes as conditions change, not just once per trip, can rack up requests fast. Teams that start on Google Maps during a pilot and then scale routing volume by 10x sometimes find the routing bill growing faster than the business metric it was meant to support. It is the right starting point when accuracy matters most and volume is still moderate, and the point to reassess once volume is high and predictable enough to make a flat-cost alternative worth the engineering investment.
Where does Mapbox fit between the other two?
Mapbox occupies the middle ground deliberately. It offers hosted Directions, Matrix, and Optimization APIs like Google, with per-request pricing, but generally at a lower cost per request and with pricing tiers that reward predictable volume. Its map data blends OpenStreetMap with its own corrections and is generally strong in the regions logistics platforms care about most. It does not have Google's live traffic depth, but for many logistics use cases (fleet routing between fixed depots, scheduled delivery windows rather than instant ETAs) that gap matters less than it does for consumer-facing, real-time navigation.
Mapbox is a common landing spot for teams that find Google too expensive at scale but are not ready to own OSRM infrastructure. It is also often the practical choice for teams building the map UI itself, since Mapbox's rendering and routing products are designed to work together.
How do request volume and region change the answer?
The comparison changes shape depending on two variables more than any brand preference: how many routing requests you make, and how concentrated your operating region is.
| Situation | Usual best fit |
|---|---|
| Low volume, need best accuracy, budget not yet a constraint | Google Maps Platform |
| High volume, concentrated region, well-mapped area, team can own infra | Self-hosted OSRM |
| Mid volume, cost-sensitive, building your own map UI too | Mapbox |
| High volume, patchy OpenStreetMap coverage in your region | Mapbox or Google, OSRM is a harder case here |
| Global footprint spanning very different mapping quality by region | Hybrid: primary engine per region, or a fallback chain |
That last row is where most platforms that scale past a single region actually land. A fixed choice made at 6 months in often stops fitting by month 18, and the platforms that avoid a painful mid-flight migration are the ones that build an abstraction layer over the routing engine from the start, so swapping or mixing providers later is a config change, not a rewrite.
Does the routing engine choice affect route optimization?
Yes, directly. Route optimization (assigning and ordering stops across a fleet, covered in depth in the next post in this series) needs a distance matrix as its core input, and how you generate that matrix, which engine, how often you refresh it, whether you cache it, is a meaningful chunk of the total system cost and latency. Some optimization libraries and commercial APIs bundle their own matrix computation; others expect you to bring your own. Knowing this dependency before you pick a routing engine avoids a second migration when you build the optimization layer on top.
What should you actually do if you are deciding right now?
Start with your real numbers, not the vendor's pricing page. Estimate routing requests per day at your current scale and at 12-month projected scale, check what fraction of your operating region is well-covered by OpenStreetMap (Google and Mapbox degrade this problem, OSRM does not), and decide honestly whether your team has the appetite to run routing infrastructure or would rather pay for it to be someone else's problem. If you are still validating the product, start hosted (Google or Mapbox) and defer the OSRM migration until volume actually justifies it. Building the routing layer behind an internal abstraction from day one is the single highest-leverage decision here, it is what makes migrating later a config change instead of a rewrite.
If you want a second set of eyes on this decision before you commit to an architecture, our automation consultants scope exactly this kind of build. The next post in this series covers what happens after routing is solved: how route optimization algorithms actually work for 3PL and fleet platforms.
Final word
There is no universally correct routing engine, only a correct one for your volume, region, and appetite for owning infrastructure. Google Maps Platform buys accuracy and zero ops burden at a real cost. OSRM buys cost control at the price of owning infrastructure. Mapbox splits the difference. The mistake to avoid is not picking wrong on day one, it is picking without an abstraction layer that lets you change your mind once you actually know your numbers.