Case study · Tech choices & rescues

How to cut your Google Maps Distance Matrix bill by 80% (and what the terms let you cache)

Google Maps API cost per request in 2026, what the March 2025 billing change did, and five ways to reduce Distance Matrix cost without losing accuracy.

By Akash Bansal, founding engineerUpdated 4 November 20269 min read

At Urban Culture, an at-home salon marketplace I ran technology for from 2020 to 2025 (500K registered users, 6 cities), we replaced Google's Distance Matrix and geocoding calls with a custom geolocation service. The result: about 80% lower cost, with accuracy held. This post explains the techniques that make a cut like that possible, what Google's 2025 pricing actually charges, and the one rule in Google's terms that decides which tricks you can legally use.

I'll be careful about one thing. I'll name the general techniques in full, but I'll describe what our service did only as far as I can back it with numbers. Where a specific belongs, I've left it out instead of rounding it up.

How much does Google Maps Distance Matrix cost per request in 2026?

Distance Matrix is not billed per request. It is billed per element, and the number of elements is the number of origins times the number of destinations. A single call asking "which of these 40 partners is closest to this customer?" is 40 billable elements.

These are the first-tier list prices from Google's global pricing page and India pricing page, checked on 4 November 2026:

Two details from Google's Routes usage and billing page move the bill more than the headline price. First, setting the TRAFFIC_AWARE or TRAFFIC_AWARE_OPTIMAL routing preference moves a matrix request from Essentials to Pro, which doubles the per-element price. Second, a single Compute Route Matrix request is capped at 625 elements (100 with traffic-aware-optimal), with a rate limit of 3,000 elements per minute.

What changed in Google Maps billing in March 2025?

On 1 March 2025, Google replaced the $200 monthly credit with a free usage cap per SKU, and moved Distance Matrix, Directions and the old Places API to "Legacy" status (Google's announcement). Three consequences matter for a marketplace:

• The free tier is now per SKU. The $200 credit used to absorb a mix of map loads, geocodes and matrix calls. Now each SKU has its own allowance, such as 10,000 matrix elements globally.
• Legacy SKUs stop discounting early. New SKUs get automatic volume discounts up to 5,000,000+ events a month. Legacy SKUs stop at the 100,000+ tier. If you are on Distance Matrix at high volume, the Routes API is cheaper at the same call pattern. On Compute Route Matrix Essentials, the per-1,000 price falls from $5.00 to $1.50 between 1M and 5M elements and to $0.38 above 5M.
• No shutdown date yet. Google says it will give at least 12 months' notice before decommissioning legacy services.

Migrating to Compute Route Matrix is the cheapest cost cut available, because it changes the price without changing your product. It is not the 80% kind of cut, though. That comes from sending fewer elements.

Why do marketplace Maps bills explode?

Because the matrix grows with the product of two things that both grow with you: demand and supply. Take an illustrative home-services marketplace. These are round numbers I made up for the arithmetic, not Urban Culture's:

• 1,500 bookings a day
• Each booking checks 50 nearby partners for travel time
• The app recomputes 1 time when the booking is placed, then again on reassignments and screen refreshes. Call it 1 + 1 extra.

That is 1,500 × 50 × 2 = 150,000 elements a day, or about 4.5 million a month. At India's $1.50 per 1,000 that is roughly $6,600 a month. At the global $5 list rate, before volume discounts, it would be about $22,000. Add partners in a city and the bill grows. Add bookings and it grows again. The per-element price was never the problem. The problem is that most of those 50 partners were never going to get the job.

Technique 1: Pre-filter with haversine distance before you call any API

The haversine formula gives the straight-line ("great-circle") distance between two coordinates. It is pure arithmetic, needs no network call, and takes microseconds. Use it to drop every partner who is obviously too far, then send only the survivors to a routing API.

The trade-off is honest and simple. Straight-line distance is not drive time. A partner 2 km away across a river can be 25 minutes away by road. So use haversine to exclude, never to decide. A generous radius (say 1.5 to 2 times your real service radius) loses almost nothing, and in a dense city it can cut a list of 50 candidates to a handful.

The same logic applies to geocoding. If the customer picked their address from a saved list, you already have the coordinates. Geocode once at save time, store the result where the terms allow (Google's terms allow latitude and longitude for 30 days), and don't geocode the same address on every booking.

Technique 2: Precompute travel times on a grid

Most marketplace questions don't need door-to-door precision. "Can this partner reach this neighbourhood in under 40 minutes?" can be answered from a table of cell-to-cell travel times. Divide the city into cells with geohash or Uber's H3 hexagons, compute travel times between cell centres, and look them up at request time.

Here is the catch, and it is the most important paragraph in this post. You cannot build that table out of Google responses. Google's Service Specific Terms give the Distance Matrix API no caching permission at all. The Routes and Directions sections allow you to cache latitude and longitude for up to 30 days, not distances or durations. The same terms also say you must not use Google Maps content with a non-Google map. That is my reading as an engineer, not legal advice. Check the current text before you rely on it.

So the grid has to come from data you own: your own routing engine (technique 3), or your own history of real trips. A marketplace collects that history for free. Every completed job has a partner start location, a timestamp and an arrival time. That is ground truth no API gives you.

Technique 3: Self-host routing with OSRM or Valhalla

This class of problem is called many-to-many routing, or computing a distance matrix. The open-source tools built for it are OSRM (its table service returns a duration matrix) and Valhalla (its sources_to_targets matrix endpoint). Both route over OpenStreetMap data, which is licensed under ODbL and needs attribution.

The marginal cost per element drops to roughly zero. You pay for a server instead. The trade-offs you're signing up for:

Best for: ranking candidates, assignment, serviceability checks, batch jobs. Not for: the ETA you promise a customer at 6 pm on a Friday, unless you've measured that it holds. A common split is self-hosted routing for the many internal decisions and one paid traffic-aware call for the single customer-facing ETA.

Technique 4: Batch, dedupe and stop recomputing

The cheapest element is the one you request once. Three habits cut volume without touching accuracy:

1. Dedupe identical pairs. Ten customers in one apartment block searching at lunch are close to one origin. Round coordinates to a sensible precision before building the request key.
2. Compute on events, not on renders. Calculate travel times when a booking is created or reassigned, store the result on the booking, and let the UI read it. Screens that call the matrix on every refresh are a classic source of runaway bills.
3. Batch up to the request limits. Pack origins and destinations into one Compute Route Matrix call (up to 625 elements) instead of many small calls, and use a field mask so you only request the fields you read.

Technique 5: Pay for traffic only where it changes the decision

Because traffic-aware routing moves you to the Pro tier, check which calls really need it. Choosing between partners 3 km and 9 km away rarely flips with traffic. The ETA you text the customer might. Keep Essentials as the default and use Pro on purpose.

What did the Urban Culture geolocation service actually do?

Here is the result in one sentence: we built a custom geolocation service that replaced Google Distance Matrix and geocoding calls across the marketplace, it cut that cost by about 80%, and the accuracy of the results held. I'm not publishing the exact bill or the internals. The techniques above are the toolbox a service like this draws on, and the principle behind all of them is the same: answer most questions with data you own, and pay per element only where it changes the decision.

The stack around it was Flutter apps on Node.js, Firebase and Cloud Functions, with operational data flowing from Firestore into BigQuery. That pipeline matters for this kind of work, because you can't claim accuracy held unless you have the data to compare against.

How do you prove accuracy held after replacing Google?

Run the new path in shadow mode first. For a few weeks, compute both the old answer and the new one for every request, serve the old one, and log both. Then compare:

• Decision agreement: how often both paths pick the same partner, or the same top 3.
• ETA error against reality: the median and 90th-percentile gap between predicted and actual arrival, from completed jobs. Compare each path against the truth, not against each other.
• Business metrics: late arrivals, partner cancellations, customer complaints about lateness.

Only cut over when the numbers say so, and keep a flag to route back to Google per city. That makes the change a two-way door.

When should you keep paying Google?

Don't build this if your matrix bill is a few hundred dollars a month. The engineering time and the server will cost more than you save. Moving from Distance Matrix to Compute Route Matrix, plus techniques 1 and 4, is a day or two of work and is usually enough. Some products can skip per-pair routing at the start: the local grocery delivery MVP prices delivery by postcode band, and the running club app uses static route maps. Build the self-hosted layer when the bill is a real line item that grows with each city you launch, and when you have trip data to check it against.

If you're running a marketplace where this bill is starting to hurt, this is the kind of build I do as a founding engineer: scoped, with weekly demos, in your repo. Here's how I work, and more engineering depth is on the engineering page. The founder-side version of this story, with dispatch and payments, is in the home-services marketplace build story.