Uber indexes the world with hexagons rather than squares for surge pricing and dispatch. Why does the shape matter, and what is the general lesson?

Why the shape matters

A square has eight neighbours at two different distances — four edge-adjacent, four corner-adjacent and further away. So "the neighbouring cells" is an ambiguous set, and anything that smooths, compares or propagates across neighbours is distorted by the geometry rather than by the data.

A hexagon has six neighbours, all edge-adjacent, all equidistant. Gradients, flood fills, smoothing and nearest-neighbour expansion behave uniformly in every direction.

For surge pricing this is a correctness property, not aesthetics: the price in one area must relate sensibly to its neighbours, and a rider should not see a price cliff from crossing a street. Uniform neighbour distance is what makes the smoothing defensible.

Why the other options are wrong

"Tile the sphere perfectly" — they do not. Hexagons alone cannot tile a sphere; twelve pentagons are mathematically unavoidable, and H3 places them over ocean.

"Subdivide cleanly" — they do not. This is H3's real trade-off: the hierarchy is approximate, because a hexagon does not decompose into whole smaller hexagons. Squares (and S2) do subdivide perfectly, which is precisely what Uber gave up.

"Storage-efficient" — not a meaningful difference; both reduce to an integer ID.

The general lesson

Choosing the right discretisation turns a geometry problem into a lookup. Every location becomes a cell ID — an integer — so it can be a partition key, cache key, map key or join key, and aggregation becomes counting by ID. This is exactly the move of choosing a good shard key, applied to space.

And the sharper version: the shape of your index constrains the correctness of what you compute on it. Most teams choose a spatial scheme for performance and silently inherit its distortions.

What a strong answer adds

Contrasting with Google's S2, which orders square cells along a Hilbert curve. Neither is universally better: S2 gives excellent locality for range scans and clean hierarchical subdivision; H3 gives uniform neighbour arithmetic. Choose by which operation dominates — containment and range queries favour S2, neighbour-relative computation favours H3.