Does DynamoDB support geospatial queries?

Not natively. DynamoDB has no geospatial data type and no distance or bounding-box operators. Geospatial queries are a modeling pattern instead: store a geohash or S2 cell ID in the key so nearby points sort together, query the cells covering your search area, then refine by exact distance in your application.

The geohash pattern

A geohash (or an S2 cell ID, as used by AWS's Geo Library for DynamoDB) encodes latitude/longitude into a string or number whose prefix identifies a grid cell — and crucially, nearby points share prefixes. Stored as a partition or sort key, that turns "points near me" into ordinary key-range queries:

• Box query — compute the cells covering a rectangle, Query each cell, merge the results.
• Radius query — same, over the cells covering a circle, then filter by exact distance client-side.

Resolution matters: pick a cell size where most searches touch only the target cell and its neighbors.

How precision changes the query count

Take the Eiffel Tower, 48.8584, 2.2945. Its geohash is u09tunquc. The Trocadéro, 640 m away at 48.8619, 2.2876, is u09tup1c0. They share u09tu, so at precision 5 they sit in the same cell. At precision 6 they do not. Two landmarks you can see from each other, in different cells, which is why a cell query always has to include the eight neighbors as well as your own.

Each character narrows the box. At this latitude:

Each row is a range because the count depends on where the circle falls against the grid, not only on how big it is. Cells also widen towards the equator, where a degree of longitude covers more ground. The same precision-5 cell is 4.9 km across at the equator and 3.2 km across in Paris.

That third column is the design decision. Precision 6 turns one "restaurants within 5 km" into roughly 190 Query calls. Precision 4 makes it one or two calls that hand back everything in a 500 km² box for you to discard client-side.

The money is not what bites. Those 190 queries, each returning under 4 KB eventually consistent, come to 95 read units, about $0.000012 per search at the us-east-1 on-demand rate, or $11.88 for a million searches. The round trips are the real cost. Issue them concurrently and cap the fan-out, or the p99 of your search endpoint is whichever cell query happened to be slowest.

Libraries and tooling

AWS published the Geo Library for Amazon DynamoDB (Java) demonstrating the S2-based pattern, and community ports exist for other languages (such as dynamodb-geo for Node.js). Check maintenance status before adopting one — the pattern itself is simple enough to implement directly.

When to use a search engine instead

For rich geo predicates (polygons, sorting by distance, combining geo with full-text), replicate the table into a purpose-built index — the same zero-ETL OpenSearch integration that handles full-text search also gives you a search engine with native geospatial queries.

Go deeper

The pattern is a sort-key trick at heart — the sort key strategies guide covers the toolbox, the expression builder generates the begins_with/BETWEEN conditions cell queries use, and DynoTable lets you inspect the encoded keys on your real items.

References

• Geo Library for Amazon DynamoDB – Part 1: Table Structure — AWS Mobile Blog
• Implementing geohashing at scale in serverless web applications — AWS Compute Blog
• Supported data types and naming rules in Amazon DynamoDB — Amazon DynamoDB Developer Guide

Last verified 2026-07-13 against the official AWS documentation linked above.

Geohashes, cell dimensions and coverage counts computed 2026-07-28 with a standard base32 geohash encoder at latitude 48.8584. Check u09tunquc against any geohash tool. The per-search cost uses the us-east-1 on-demand read rate in our synced pricing table (AWS pricing API publication 2026-07-22).