At the center of Uber's business is a marketplace problem: match riders who want a car to drivers who are nearby, price that match fairly given current supply and demand, and do it continuously across every city Uber operates in. All of that depends on answering spatial questions fast — which drivers are near this pickup point, how is demand distributed across a neighborhood, where should surge pricing boundaries fall — at a volume that makes brute-force distance calculations impractical. Uber's engineering team needed a way to divide the map into indexable regions that could be queried, aggregated, and compared cheaply.

Why squares and geohashes fell short

Early approaches at Uber, like many geospatial systems, used square or rectangular grid cells — geohashes or quadtree-style indices (similar in spirit to Google's S2 library). These work, but square cells have an awkward geometric property: not all neighbors are equidistant. A cell sharing an edge with its neighbor is closer than one sharing only a corner, which distorts distance-based calculations and makes anything derived from adjacency — like drawing a smooth surge pricing boundary — look blocky and unnatural rather than reflecting the real underlying demand pattern.

Hexagons and the H3 grid

Uber's answer was H3, a hierarchical hexagonal grid system. Hexagonal cells have a property squares don't: every cell has six neighbors, and all six are (with very close to) equal distance from the center. That uniformity makes distance-based aggregation, smoothing, and visualization much more natural — a heatmap of driver density or a surge multiplier drawn on hexagons follows the real geographic gradient instead of an artifact of the grid shape.

H3 is hierarchical: it defines roughly fifteen resolutions, from huge cells covering large regions down to small ones a few meters across, and cells at one resolution nest cleanly into the cells of a coarser resolution. That lets Uber's systems trade precision for aggregation speed depending on the task — fine resolution for matching a specific rider to nearby drivers, coarse resolution for city-wide demand forecasting — using the same underlying index rather than maintaining separate systems.

One geometric wrinkle is unavoidable on a sphere: you cannot tile a sphere entirely with hexagons. H3 handles this by allowing exactly twelve pentagon cells at fixed locations in the grid, positioned deliberately away from populated areas where possible, so the vast majority of real-world queries never touch them.

Uber uses H3 across dynamic pricing, ETA estimation, driver positioning and heatmaps, and as a general spatial feature-engineering tool for machine learning models that need to bucket location data. In 2018, Uber open sourced H3, and it has since been adopted well beyond ride-hailing, in geospatial analytics, logistics, and mapping tools at other companies.

What you can borrow

  • Choose data structures that match your domain's actual geometry, not just what's most familiar — a grid's shape has real downstream effects on the quality of derived calculations like distance and smoothing.
  • Hierarchical indexing lets one system serve both fine-grained and coarse-grained queries by choosing resolution, instead of building and maintaining separate systems for each granularity.
  • Accept known, documented edge cases (like H3's twelve pentagons) rather than chasing a perfect solution that doesn't exist for the underlying geometry.
  • Open sourcing an internal tool that solves a genuinely general problem can build goodwill and attract external contributions and hardening you wouldn't get keeping it private.