Redis vs Memcached for Geospatial Queries
Geospatial features (nearest-neighbour, radius search, bounding-box queries) are the kind of feature you bolt onto a product later and discover you need a real index. Redis ships a geohash-backed implementation that handles the 95% case in one command.
How Redis encodes geo coordinates
The Redis GEO commands are built on top of sorted sets. When you call GEOADD points 13.361389 38.115556 "Palermo", Redis converts the longitude / latitude pair to a 52-bit integer geohash, then stores that integer as the score in a sorted set under the key points with member name Palermo. The clever part is that the geohash is interleaved-bit encoded, so geographically close points produce numerically similar scores.
That correspondence makes range queries on the sorted set approximately equivalent to spatial queries. To find everything within 50km of a given point, Redis computes the geohash for the query point, determines which range of geohash values could possibly contain a point within 50km (the bounding box in geohash space), runs a sorted-set range query, and then filters the candidates with exact haversine distance calculation. The candidate set is small compared to the full data set, so the operation is efficient even with millions of points.
This is also why Memcached cannot do geospatial queries even in principle. Without an ordered data structure, you cannot do range queries; without range queries, every spatial query becomes a full scan. For a thousand points this is fine, for a million it is impractical, for a hundred million it is impossible. Redis's choice to back GEO on sorted sets gives it the asymptotic complexity needed for production geospatial workloads.
GEOSEARCH for radius queries
# Index drivers GEOADD drivers 13.361389 38.115556 "driver:42" GEOADD drivers 13.583333 37.316667 "driver:43" # Find all drivers within 50 km of a pickup point GEOSEARCH drivers FROMLONLAT 13.5 38.0 BYRADIUS 50 km ASC COUNT 10 WITHCOORD WITHDIST # Find nearby points relative to an existing member GEOSEARCH drivers FROMMEMBER "driver:42" BYRADIUS 30 km ASC # Bounding box (rectangle) instead of circle GEOSEARCH drivers FROMLONLAT 13.5 38.0 BYBOX 100 100 km ASC COUNT 50
Real-world: ride-hailing, delivery, find-nearby
The driver-location and rider-pickup matching at the heart of every ride-hailing app is a Redis geospatial workload at its core. The dispatch system continuously updates each driver's location (GEOADD on every position ping, typically every few seconds), and on every rider request runs GEOSEARCH within a few hundred metres to find candidate drivers. Uber, Lyft, Grab, Didi and Bolt have all spoken at conferences about variants of this pattern, sometimes layered on top of more specialist systems for the actual matching algorithm.
Food delivery (DoorDash, Deliveroo, Just Eat, Uber Eats) uses similar shapes for restaurant-to-customer matching and delivery-fleet routing. The DoorDash engineering blog has discussed using Redis sorted sets and geo commands for the matching layer. Find-nearby features in social apps (Tinder, Bumble, Snap Map) and store-locator features in retail apps frequently land on the same primitives.
For more specialised work the recommendation is to look at Tile38, which is Redis-protocol-compatible and adds polygon support, persistent indexes, and bounded-area subscriptions (notify me when an object enters this geofence). PostGIS in Postgres is the right choice when geospatial queries need to join against business data in the same transaction. The Redis geo commands are the right choice for a fast-changing hot index, where the same data is also being scanned by the rest of your application.
Limits and gotchas
The Redis GEO commands cover circles and rectangles. Arbitrary polygons (delivery zones with awkward shapes, congestion charge boundaries, voting districts) are not supported directly. You can approximate by storing the polygon vertices separately and doing point-in-polygon checks in your application code after a bounding-box query, or use Tile38, or use PostGIS. Tile38 specifically was designed to handle polygon-and-geofence workloads that Redis cannot.
The other limit is altitude. Redis GEO is 2D only; it stores lat/lon and ignores elevation. For most applications this is fine, but flight planning, indoor positioning, and any 3D workload need a different store. The accuracy at the poles also degrades because the projection is not preserved equally at all latitudes; for applications operating above 80 degrees latitude (rare but real for arctic logistics) you would want a polar projection rather than the geohash-on-sphere model.
Finally, the GEO commands cluster by key (the sorted set), not by region. If your geo index is one giant key, you cannot shard it across Redis Cluster nodes without breaking GEOSEARCH (which can only operate on data in a single hash slot). The common production pattern is one geo set per region (UK, US-East, Brazil, etc.), with the application routing queries to the right key. This gives you horizontal scaling at the cost of cross-region queries being unsupported, which usually matches the product reality.
FAQ
What is a geohash?
Geohash is an encoding that maps a latitude/longitude pair to a single base32 string (or 52-bit integer in Redis). Nearby points produce similar prefixes, so a range query over geohash values returns geographically clustered results. Redis uses 52-bit geohash internally for the GEO commands.
How accurate is GEORADIUS?
Accurate enough for typical radius search (delivery zone, nearby store, taxi pickup). Redis uses the haversine formula on the Earth's surface assuming a sphere. The error is sub-meter at street scale, growing to ~0.5% at continental scale because Earth is an oblate spheroid not a perfect sphere. For ride-hailing and food delivery this is well below the noise of GPS itself.
Can Memcached do geospatial queries?
Not natively. You can encode lat/lon as JSON values and fetch by key, but spatial queries (within radius, k-nearest) require fetching all data and computing in application code. For more than a few hundred points this is hopeless. The standard alternatives are PostGIS in Postgres, a dedicated geospatial database like Tile38, or Redis.
GEORADIUS vs GEOSEARCH?
GEOSEARCH (Redis 6.2+) is the modern replacement for GEORADIUS and GEORADIUSBYMEMBER. Same capabilities, cleaner syntax, supports both circular and rectangular bounding-box queries. Use GEOSEARCH in new code; GEORADIUS still works but is deprecated.
What about Tile38, PostGIS, S2?
Tile38 is a dedicated open-source geospatial database with Redis-like protocol, supports polygons and complex predicates, used at scale for fleet tracking. PostGIS is the gold standard for SQL-based GIS with arbitrarily complex queries. Google's S2 library implements spherical geometry primitives, often paired with another store. Redis is the right call when geospatial is one feature among many; use a specialist when geospatial is the product.