Once you can store geometry types and run spatial queries with distance in mind, most product features follow a small set of patterns.
Store finder (“near me”)
Store each site's coordinates as a Point, optionally with a category and opening hours. At query time, supply the user's location, compute distance or bounding-box filters, and sort by proximity. For dense datasets, consider geohash prefixes or spatial indexes (where supported) to avoid scanning the whole table.
For example, consider records used to store millions of events by location. These can use array-based record IDs that start with a geohash, making it easy to query every record with exactly this hash and no need to use any further filtering.
Service areas and delivery zones
Represent coverage as polygons (or multipolygons for islands). New customers or orders are classified with point-in-polygon tests.
For a single zone record, store the boundary as a polygon geometry and test whether a customer’s location falls inside it using CONTAINS (polygon on the left, point on the right):
A point outside the ring (for example further north) returns no records. For overlapping territories, you may return several matches and disambiguate with priority, postal rules, or extra fields on service_area.
Tracking and corridors
For vehicles or assets reporting on a schedule, store recent positions as points with timestamps and use line strings or buffers when you care about adherence to a route corridor rather than a single snapshot.