latlng

latlng vs Redis GEO: beyond nearby search

Redis GEO commands turn a sorted set into a fast point index. latlng is a dedicated geospatial engine with polygons, fields, and geofence events. If you only need nearest-point lookups, Redis may be all you need — here's where the line is.

Reviewed against latlng v0.2.0 and the Redis GEO command set · Updated September 27, 2026 · Redis GEO docs · Valkey

Summary

  • Redis GEO is excellent at radius and box search over points, and it's already in most stacks.
  • It has no polygons in the GEO commands, no per-member fields or TTLs, and no geofence events — enter/exit logic lives in your application.
  • latlng adds GeoJSON areas, filterable fields, per-object TTLs, built-in enter/exit/cross/roam detection, and durable webhook delivery.

Feature comparison

What it is Geospatial object engine and geofencing server A set of commands for points stored in a sorted set, inside a general-purpose key-value store
License MIT Redis 8: AGPLv3, RSALv2, or SSPLv1. Valkey, the Linux Foundation fork, keeps the GEO commands under BSD-3
Geometry Points, bounding boxes, geohashes, and GeoJSON (lines, polygons, multi-geometries, collections) Points only (longitude, latitude, member name)
Searches NEARBY (radius), WITHIN and INTERSECTS against circles, boxes, polygons, tiles, and sectors; SCAN; text SEARCH GEOSEARCH by radius or box around a point or member; GEODIST, GEOPOS, GEOHASH
Per-object data Numeric and string fields plus JSON documents per object, filterable in queries None on the GEO member itself; store attributes in separate keys and join in application code
Per-object expiry TTL per object (EXPIRE / PERSIST); expiries fire Del geofence events TTL on the whole key only, not on individual members
Geofence events Built in: inside, outside, enter, exit, cross, and roam detection None. Keyspace notifications only report that a key changed, not that a point crossed a boundary
Event delivery Durable HTTP webhooks with retries and dead-letter; live channels over WebSocket and Cap'n Proto Pub/Sub and Streams are available, but your application must compute and publish the events
Protocol and clients HTTP/JSON with OpenAPI, WebSocket, Cap'n Proto; TypeScript SDK RESP; mature clients for virtually every language
Authentication Bearer tokens and JWT/JWKS with per-collection permissions ACL users with per-command and per-key-pattern permissions
Persistence and HA Append-only file with verify, backup, restore; single-leader follower replication RDB snapshots and AOF; replication, Sentinel, and Redis Cluster. One GEO key lives on one shard
Managed hosting Self-hosted (binary, Docker, Homebrew) Offered by every major cloud provider
Runs in the browser Yes — @latlng/wasm in a Web Worker No

Nearby search: Redis already does this well

If all you need is "which drivers are within 2 km of this rider", Redis GEO is hard to beat. GEOADD stores each point as a 52-bit geohash score in a sorted set, and GEOSEARCH returns the members within a radius or box, sorted by distance. It is fast, and if you already run Redis, you get it for free.

latlng answers the same question with NEARBY, and adds optional field filters, glob matching on IDs, cursors, and different output shapes (full objects, points, IDs, counts) in the same call.

Redis 
GEOADD fleet 9.99 53.55 truck1

GEOSEARCH fleet FROMLONLAT 9.99 53.55 \
  BYRADIUS 1000 m ASC WITHDIST
latlng (HTTP/JSON) 
curl -X POST localhost:7421/collections/fleet/objects/truck1 \
  -d '{"object":{"Point":{"lat":53.55,"lon":9.99,"z":null}}}'

curl -X POST localhost:7421/collections/fleet/search/nearby \
  -d '{"lat":53.55,"lon":9.99,"meters":1000,"options":{}}'

Where Redis GEO stops

Redis GEO members are points and nothing else. There is no polygon type, so questions like "is this truck inside the depot" or "which delivery zones does this route cross" have to be answered in application code, usually by fetching candidates with a box search and testing each one with a geometry library.

Newer Redis releases include the Redis Query Engine, whose GEOSHAPE fields can index polygons on hash or JSON documents and run WITHIN and CONTAINS-style queries. That closes part of the gap for static shapes, but it is a separate indexing system on top of documents, and it still doesn't produce events when objects move.

latlng stores points, boxes, and full GeoJSON geometries in one R-tree, and runs WITHIN and INTERSECTS against circles, boxes, polygons, XYZ tiles, quadkeys, sectors, or other stored objects.

Geofencing is the real difference

To build enter and exit alerts on Redis, you have to keep each object's previous zone membership somewhere, re-run a search on every position update, diff the results, and publish the changes yourself — then make sure that pipeline survives restarts and retries failed deliveries.

In latlng, a geofence is a stored query. Register it once as a hook or channel, and every SET that changes an object's relationship to the fence emits inside, outside, enter, exit, cross, or roam events. Webhook jobs are written to the durable log together with the mutation, delivered with exponential backoff, and dead-lettered instead of dropped when a receiver stays down.

Operational fit

Redis is everywhere: managed offerings on every cloud, mature ACLs, Sentinel and Cluster for high availability, and client libraries for every language. Note that a single GEO key lives on one cluster shard, so very large point sets need to be split across keys by region or tenant.

latlng is a young, self-hosted project. It runs as a single binary or container with append-only persistence, read-only follower replication, Prometheus metrics, and per-principal rate limits, and the same engine can also run inside a browser tab.

Choose latlng when

  • You need polygons or GeoJSON areas, not just points.
  • You want enter, exit, and cross events without building and operating the diffing pipeline yourself.
  • Geofence events should reach other services as durable, retried webhooks.
  • Objects carry fields or JSON you want to filter on, or need individual TTLs.

Choose Redis GEO when

  • You only need radius or box searches over points, such as nearest-driver lookups.
  • You already run Redis (or Valkey) and want to avoid another service.
  • You need a managed service from your cloud provider or clients in many languages today.
  • Your geospatial data is a small part of a larger caching or messaging workload.

Frequently asked questions

Can Redis do geofencing?

Not natively. Redis GEO can find points inside a radius or box, but it has no geofence objects and emits no enter or exit events. You can build geofencing on top by storing previous state, re-querying on every update, and publishing changes through Pub/Sub or Streams from your application.

Does Redis GEO support polygons?

The GEO commands only store points. The Redis Query Engine in newer Redis versions adds GEOSHAPE fields that can index polygons on hash or JSON documents, but that is a separate document index and does not produce geofence events.

Is latlng compatible with the Redis protocol?

No. latlng exposes HTTP/JSON (with an OpenAPI document), WebSocket, and Cap'n Proto transports, plus a TypeScript SDK. Redis clients cannot talk to it directly.

Can I use latlng and Redis together?

Yes, and it's a common split: keep Redis for caching, sessions, and queues, and run latlng for spatial indexing and geofence events. latlng webhooks can feed a service that writes into Redis Streams if other consumers already read from there.

More comparisons

latlng vs Tile38

Two geofencing servers with the same object and fence model. Tile38 brings RESP, Lua, and a dozen hook destinations; latlng brings durable webhooks, JWT auth, and a browser build.

 latlng vs PostGIS

PostGIS is the spatial SQL database of record. latlng is an in-memory engine for live positions and push-based geofence events — often used next to it.
← All comparisons Try latlng →