BTrDB VS s2geometry

Check out http://btrdb.io/ which is a similar idea. It's a distributed database as well. It was designed for storing billions or even trillions of records for electrical data from hundreds of sources at once.

It was written by a couple of friends of mine and others, so I'm not sure how it compares to the article link, as I'm not a databases expert.

I experimented with geospatial Hilbert Curves as a Postgres extension [0] for PostGIS using the S2 [1] spherical geometry library. S2 uses a scale free cell coverage pattern that is numbered using six interlocking space filling Hilbert Curves [2].

By having both high level (cell) and low level (cell id) geometries it was a very powerful library which allowed projection from the hilbert space into a Postgres spatial index (spgist) including various trees, like noted in this article. It appears to be still quite active in development.

[0] https://github.com/michelp/pgs2

[1] https://s2geometry.io/

[2] https://s2geometry.io/devguide/s2cell_hierarchy

If you check the h3geo comparison page, you should see plenty of alternatives to geohash, such as s2 or even h3 itself.

See some discussion I started at https://github.com/google/s2geometry/issues/190

> It was quite hard for me to find open-source implementations of linear quadtrees.

You probably know this, but the S2 library has one: https://github.com/google/s2geometry

https://s2geometry.io shows how this works

If your points are distributed globally, however, I'd suggest using something like s2geometry (calculates over a sphere instead of an ellipsoid which is much faster + already has something called S2ClosestPointQuery).

Some alternative solutions are S2 from Google and H3 from Uber. These don't have the same issues as geohash because they work on a 3-d model of the geoid and not a 2-d cylindrical projection like Geohash.