Geohashes: Are We Optimizing the Wrong Things?

Geohashes are short strings or integers that represent locations on Earth.

Most software engineers never think about them. Yet they quietly power a surprising number of systems, from "find nearby" searches to ride-sharing, food delivery, maps, and spatial databases.

So what makes a good geohash approach?

What Do We Actually Need?

In practice, geohashes are primarily used as database keys.

Their job is simple: quickly narrow the search before performing exact geometric calculations.

For that purpose, a geohash should satisfy a few practical requirements.

1. Every single location should always produce the same geohash.
2. At a given precision, every geohash should correspond to exactly one spot on the Earth surface.
3. Cells should have approximately the same physical size everywhere on Earth.
4. Cell shapes should remain reasonably compact rather than becoming extremely stretched in random directions.
5. Encoding and decoding should be extremely fast.
6. Results should be deterministic across hardware, operating systems, compilers, and floating-point implementations.
7. The encoding should waste as little code space as possible. There should be no bit or character combinations that aren't correct geo positions
8. Most importantly, it should be easy to generate the set of geohashes covering an arbitrary region around a given point — a circle, a viewport, a route, or any other shape.

Strictly speaking, these requirements are sufficient for almost every usage scenario.

Some distributed databases also benefit from another property: Similar prefixes should usually correspond to nearby locations. This makes geographic sharding easier. Notice the wording: usually.

The reverse requirement — nearby locations should always have similar geohashes — is mathematically impossible. Any mapping from a sphere to a one-dimensional code must contain discontinuities. Somewhere on Earth there will always be locations that are physically adjacent but receive completely different identifiers.

The important question is therefore not whether discontinuities exist. They must. The real question is: How difficult are they to deal with?

The Three Dominant Geohash Systems

Today, three geohash families dominate practical use:

• Classic Geohash
• Google S2
• Uber H3

Each represents a different design philosophy.

More details can be found here: geospatial-indexing-explained

Classic Geohash

Classic Geohash is beautifully simple.

It recursively subdivides latitude and longitude into rectangles and interleaves the resulting bits.

Its advantages are substantial:

• extremely fast
• deterministic
• excellent prefix hierarchy
• no wasted code space
• only one discontinuity (the antimeridian), represented as a straight vertical line

Unfortunately, it has a fundamental weakness: its cell width shrinks with latitude.

Near the poles, cells become arbitrarily small.

At high latitudes, covering the same physical search radius may require tens or hundreds of times more geohashes than at the equator.

The database query grows accordingly.

Google S2

Google approached the problem differently. "And this changes everything"™ (just kidding). Instead of working directly with latitude and longitude, S2:

• projects Earth onto the six faces of a cube,
• each face is then subdivided using a Hilbert curve.

This greatly improves geometric quality. Cells remain nearly uniform in size across the globe, and shape distortion is small.

Those improvements come at a cost.

The projection itself is mathematically sophisticated, involving heavy floating-point arithmetic, transcendent functions, coordinate normalization, multiple projection stages, and nonlinear corrections. The implementation is correspondingly complex.

Topology also becomes more complicated. Instead of one discontinuity, S2 introduces twelve cube edges and eight cube corners where three faces meet. Coverage algorithms must correctly handle every one of these cases.

Encoding efficiency is another trade-off. Three bits are required to encode six cube faces, leaving two unused values. An additional sentinel bit further reduces usable code space. Overall, roughly 62% of the possible integer values cannot represent any location without duplications.

H3

Uber's H3 takes yet another approach.

Instead of squares, it builds a hierarchical grid of mostly hexagonal cells.

The result is an elegant geometric mesh with excellent local neighborhood properties and nearly uniform cell sizes.

However, maintaining a hexagonal hierarchy on a sphere is mathematically difficult. The system requires pentagons, special traversal rules, and significantly more bookkeeping than rectangular systems.

Unlike Classic Geohash, H3 is not naturally prefix-based. Simple prefix truncation or bit tricks do not produce parent cells, making some database operations less straightforward.

Its encoding also leaves a significant portion of the possible code space unused.

Like S2, H3 prioritizes geometric quality over encoding simplicity.

How Geohashes Are Usually Compared

Most articles compare geohashes using geometric properties.

Classic Geohash

• Cell size uniformity ❌Poor
• Cell shape uniformity ❌Poor
• Local neighborhood handling ✅Good
• Projection distortion ❌ High

Google S2

• Cell size uniformity ✅Excellent
• Cell shape uniformity ✅Excellent
• Local neighborhood handling ⚠️Poor at edges
• Projection distortion ✅Low

Uber H3

• Cell size uniformity ✅Excellent
• Cell shape uniformity ✅Excellent
• Local neighborhood handling ⚠️Poor at edges and pentagons
• Projection distortion ✅Low

Looking only at this table, S2 and H3 appear to be clear winners.

But there's a problem. And this is the key thing most people miss.™ (Sorry, for my AI-thong)

What Actually Matters in Production

Databases do not search geometry. They are search keys.

For real systems, the more relevant questions are different.

Classic Geohash

• Deterministic (bit-perfect) encoding ✅Excellent
• Encoding speed ✅Excellent
• Encoding efficiency ⚠️Good (100% code-space utilization, alas unevenly due distortions)
• Simplicity of coverage generation ✅Good
• Number of discontinuities to handle ✅1 (one vertical line)
• Predictable query size ❌Poor

Google S2

• Deterministic encoding ⚠️Non-trivial
• Encoding speed ❌Poor
• Encoding efficiency ❌Poor
• Simplicity of coverage generation ❌Poor
• Number of discontinuities to handle ❌12 Great circles, 8 vertexes
• Predictable query size ✅ Excellent

Uber H3

• Deterministic encoding ⚠️Non-trivial
• Encoding speed ❌Poor
• Encoding efficiency ❌Poor
• Simplicity of coverage generation ❌Poor
• Number of discontinuities to handle ❌Multiple non-trivial hexagon and pentagon edges.
• Predictable query size ✅ Excellent

This tells a very different story.

A Different Optimization Target

Classic Geohash, S2, and H3 are often presented as competing solutions to the same problem. They are not.

Classic Geohash was designed primarily as an efficient indexing scheme.

S2 and H3 were designed primarily to improve geometric properties of the underlying spatial partition.

Those are related problems—but they are not the same problem.

If your primary goal is geometric manipulations, mesh quality, or spatial analysis, S2 and H3 are good choices.

If your primary goal is generating compact, deterministic, database-friendly search keys, the trade-offs look very different (all three are different but equally bad).

And that raises an interesting question:

Can we keep the simplicity, speed, and prefix properties of Classic Geohash while eliminating its unbounded distortion near the poles?

In the next article, I'll describe one possible answer: Double Diamonds (DD) geohash. It keeps the database-oriented strengths of Classic Geohash while addressing its largest practical limitation.

To be continued...