Three prevailing themes
| # | Theme | Key quotes |
|---|---|---|
| 1 | Congruency matters for fast joins and analytics | “If joins are a critical performance‑sensitive operation, the most important property of a DGGS is congruency.” – jandrewrogers “Congruency allows for much more efficient join schedules and maximizes selectivity.” – jandrewrogers “Congruent shards also tend to be more computationally efficient generally, which does add up.” – jandrewrogers |
| 2 | H3 is tuned for visualization/aggregates, not for analytic joins | “H3 is not congruent it was optimized for visualization, where congruency doesn’t matter, rather than analytical computation.” – jandrewrogers “H3 is great for doing point geometry aggregates. It shines at that. Not so much geospatial joins though.” – jandrewrogers “To me, the big selling point of H3 is that once you’re ‘in the H3 system’, many operations don’t need to worry about geometry at all.” – ajfriend |
| 3 | Practical solutions often use native spatial indexes or hybrid approaches | “We make a set of H3 indexes … and store them in Elasticsearch. Geospatial queries become full‑text search queries.” – cullenking “Elasticsearch and Opensearch have a built‑in geo_shape type that is a bit more optimal for queries like this.” – jillesvangurp “Wouldn’t having a spatial index give you most of the performance gains… without needing H3?” – febed |
These threads show that while H3 is popular for its simplicity and visualization strengths, its lack of congruency limits join performance, and many practitioners prefer native spatial indexes or hybrid schemes for large‑scale analytic workloads.