# Geohash vs H3 > Geohash is a rectangular spatial encoding with exact prefix-based subdivision; H3 is a mostly hexagonal grid with convenient neighborhood operations and a logical hierarchy. Choose Geohash for simple prefix-based indexing, and H3 for neighborhood aggregation or spatial smoothing. Neither replaces exact distance filtering or solves geographic load skew. Source: https://sysround.com/compare/geohash-vs-h3 Updated: 2026-11-05 ## Side by side | | Geohash | H3 | |---|---|---| | Cell shape | Latitude-longitude rectangles | Mostly hexagons, with 12 pentagons per resolution | | Hierarchy | Shorter prefixes exactly contain their descendants | Logical parent-child hierarchy; boundaries do not nest exactly | | Storage access | Prefix or ordered-range lookups | Cell-ID lookups; explicit hierarchy operations | | Nearby search | Cover the search region with neighboring cells | Use neighborhood traversal or a region cover | | Distance interpretation | Cell dimensions vary with latitude and precision | Grid steps are not a fixed distance in meters | | Spatial aggregation | Straightforward prefix-based rollups | Convenient neighborhood aggregation and smoothing | | Area uniformity | Same-length cells shrink in area toward the poles | Cell areas still vary; not an equal-area grid | | Load distribution | Dense regions can create hot prefixes | Dense regions can create hot cells | ## The differences that matter Geohash interleaves longitude and latitude bits, commonly represented as a string. Removing characters produces a larger rectangle that exactly contains the original cell. This fits prefix indexes and ordered key ranges, but points just across a cell boundary can have very different prefixes, so nearby search must query multiple cells. H3 provides cell IDs and operations for traversing neighboring cells. Its mostly hexagonal layout is useful for neighborhood counts, heatmaps, and smoothing because ordinary hexagons have six edge neighbors. Pentagon cells and grid distortion require library-supported handling rather than assumptions about a perfect planar hex grid. The hierarchy behaves differently. Geohash descendants are geometrically contained by their prefix cell. H3 assigns each cell a logical parent, but child boundaries do not exactly fit within the parent's boundary. Rolling up fine-cell counts by parent is valid for that logical hierarchy, but can differ from assigning the original coordinates directly at the coarser resolution. For a radius query, both are candidate-generation tools. Enumerate cells that conservatively cover the search region, retrieve candidates, then apply an exact geographic distance check. A fixed number of neighboring cells does not guarantee coverage for every radius and location, and H3 polygon-cover modes based only on cell centers can miss boundary candidates. ## Choose Geohash when - Your storage engine supports efficient prefix or ordered-range scans, and you want a straightforward spatial key. - You need exact geometric containment between parent cells and their descendants. - Your application mainly performs nearby lookup, and a rectangular candidate cover plus exact filtering meets its requirements. - You want variable spatial precision expressed through shorter or longer prefixes, without relying on specialized grid traversal. ## Choose H3 when - You aggregate supply, demand, or events by cell and frequently combine neighboring cells. - You need grid-neighborhood operations for heatmaps, smoothing, or expanding a candidate search. - You want a mostly hexagonal global grid and can explicitly handle pentagons, area variation, and boundary behavior. - Your application benefits from logical multiresolution rollups and does not require exact geometric nesting. ## Worked example: Driver discovery versus demand aggregation Suppose a city has 100,000 active drivers, each reporting a location every 5 seconds: about 20,000 updates per second before retries. Matching needs available drivers within 3 kilometers, while pricing needs neighborhood-level demand and supply counts. Geohash can support matching through prefix-based candidate lookups; H3 can support matching too and makes neighboring-cell aggregation convenient. For either choice, cover the full search circle and filter candidates by exact distance. Do not assume one cell or one neighbor ring is sufficient. Keep driver freshness and availability separate from cell membership, and use an atomic assignment step after discovery. The grid finds candidates; it does not reserve a driver. ## In the interview - Start with the operation: radius search, nearest candidates, density aggregation, or regional pricing. Explain which grid property helps that operation rather than claiming one index is universally faster. - Describe the complete read path: choose a resolution, cover the query region, fetch candidates, filter by exact distance, then rank. Expect questions about boundary misses, candidate volume, and sparse regions. - Separate the spatial index from physical partitioning. Hashing cell IDs across shards can distribute different cells, but a single dense cell may still need subpartitioning or finer indexing. - For moving entities, explain location freshness, stale memberships, and cross-cell updates. Interviewers may probe duplicate candidates, expired locations, and race-free assignment after discovery. - For aggregation, define whether counts belong to logical cells or exact geographic polygons. With H3, explain why parent rollups can differ from reindexing coordinates at a coarser resolution. ## Common mistakes - Searching only the containing cell, or assuming the immediate neighbors always cover the requested radius. - Treating H3 cells as equal-area or converting a grid-ring count directly into a guaranteed distance in meters. - Assuming H3 children fit exactly inside parent boundaries, as Geohash prefix descendants do. - Using either encoding as a complete solution to hot shards, stale locations, or exclusive driver assignment. ## Interview questions where it comes up - [Design a ride hailing app like Uber](https://sysround.com/questions/design-uber): Compare spatial candidate lookup, moving-driver index maintenance, and dense-cell hotspots before the assignment step. - [Design Uber surge pricing](https://sysround.com/questions/design-surge-pricing): Cell shape, neighboring-cell smoothing, and multiresolution rollups affect how demand and supply become regional prices. - [Design a dating app like Tinder](https://sysround.com/questions/design-tinder): Location-based discovery needs complete radius coverage before distance, privacy, and exclusion filters are applied. - [Design a restaurant review app like Yelp](https://sysround.com/questions/design-yelp): Nearby restaurant retrieval uses spatial cells to generate candidates before exact distance filtering and ranking. - [Design a food delivery app like DoorDash](https://sysround.com/questions/design-doordash): Courier discovery requires fresh spatial membership and boundary-safe searches before exclusive assignment. ## FAQ ### Is H3 better than Geohash for nearby search? Not universally. H3 offers convenient neighborhood traversal, while Geohash fits prefix-based storage access. Both require a complete candidate cover and exact distance filtering; compare lookup fan-out, candidate counts, and update cost for your workload. ### Are H3 cells equal-area, and do their children fit inside parents? No. H3 cell areas vary, and its hierarchy is logically nested rather than exactly geometrically nested. Use actual cell areas for density calculations, and distinguish parent-based rollups from counts produced by indexing coordinates directly at a coarser resolution. ### Can Geohash or H3 be used for database sharding? Yes, but spatial keys do not guarantee balanced traffic. A busy downtown cell can be much hotter than many rural cells combined. You may need finer cells, per-cell subshards, or a separate mapping from spatial cells to physical partitions. ## Related concepts - [Geohash](https://sysround.com/concepts/geohash) - [H3 hexagonal grid](https://sysround.com/concepts/h3) - [Partitioning strategies](https://sysround.com/concepts/data-partitioning) - [Hot keys and hot partitions](https://sysround.com/concepts/hot-keys) - [Database indexing](https://sysround.com/concepts/database-indexing) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.