Redis’s geospatial commands are surprisingly efficient because they don’t actually store latitude and longitude directly. Instead, they use a technique called Geohashing to convert latitude/longitude pairs into a single string, which is then stored in a sorted set. This allows Redis to leverage its highly optimized sorted set operations for location-based queries, making it incredibly fast for finding nearby points.
Let’s see this in action. Imagine we’re building a simple "find nearby restaurants" feature.
First, we need to add some locations to our Redis instance. We’ll use the GEOADD command. The syntax is GEOADD key longitude latitude member.
redis-cli> GEOADD restaurants 2.3522 48.8566 "Eiffel Tower"
(integer) 1
redis-cli> GEOADD restaurants 2.3488 48.8530 "Louvre Museum"
(integer) 1
redis-cli> GEOADD restaurants 2.3631 48.8738 "Sacré-Cœur Basilica"
(integer) 1
redis-cli> GEOADD restaurants 2.3159 48.8462 "Champ de Mars"
(integer) 1
Now, let’s say a user is standing near the Eiffel Tower and wants to find restaurants within 5 kilometers. We use the GEORADIUS command: GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [COUNT count] [ASC|DESC].
Here, we’ll search for points within 5 kilometers of the Eiffel Tower’s coordinates:
redis-cli> GEORADIUS restaurants 2.3522 48.8566 5 km WITHDIST WITHCOORD
1) 1) "Eiffel Tower"
2) "0.0000"
3) 1) "2.3522"
2) "48.8566"
2) 1) "Louvre Museum"
2) "3.9999"
3) 1) "2.3488"
2) "48.8530"
3) 1) "Champ de Mars"
2) "1.7272"
3) 1) "2.3159"
2) "48.8462"
The output shows the members within the radius, their distance from the center point, and their coordinates. Notice how "Sacré-Cœur Basilica" (which is further north) isn’t included because it’s outside the 5km radius.
The core problem Redis Geo commands solve is efficiently querying points based on their geographical proximity without the overhead of complex spatial indexing databases. It achieves this by mapping 2D coordinates to a 1D representation (Geohash) that can be stored and queried using Redis’s sorted set data structure. The GEORADIUS command, for instance, doesn’t iterate through every point; it uses the Geohash to quickly narrow down the search space.
Internally, when you use GEOADD, Redis calculates a Geohash for the given latitude and longitude. This Geohash is a string of characters that represents a bounding box on the Earth’s surface. Longer Geohashes represent smaller, more precise bounding boxes. Redis stores these Geohashes as members in a sorted set, with their score being the Geohash itself (or a numerical representation of it).
When you execute GEORADIUS, Redis uses the provided coordinates to calculate a set of Geohashes that cover the specified radius. It then queries the sorted set for members whose Geohashes fall within this calculated range. The WITHCOORD and WITHDIST options trigger additional calculations to return the original coordinates and the precise distance, respectively, after the initial filtering based on Geohash.
The key levers you control are the key (your dataset name), the longitude and ``latitudeof your query point, and theradius with its unit (m, km, ft, mi). You can also control the number of results with COUNTand the order withASC(ascending distance) orDESC` (descending distance).
A common point of confusion is how GEORADIUS handles points that are exactly on the edge of the search radius. Redis is precise here; if a point’s calculated distance is exactly equal to the radius, it will be included. This is unlike some other spatial indexing systems that might have edge-case ambiguities. The Geohashing algorithm itself is designed to ensure that points within a certain radius are likely to share a common prefix in their Geohash, making the initial lookup efficient.
The next logical step is to explore how to find the distance between two specific points using GEODIST or how to get the members within a bounding box using GEOHASH and ZRANGEBYLEX.