Why PostGIS Matters: The Technical Edge Behind Great Directory Search

The Search Problem Most Directories Get Wrong

When a consumer types “plumber near 90210,” they expect to see the closest plumbers, sorted by distance. Simple, right?

Most directory platforms handle this with one of two approaches — both of which are wrong.

Approach 1: ZIP Code Matching

Store a ZIP code for each listing. When someone searches “90210,” query WHERE zip = '90210'. This misses providers in adjacent ZIP codes, doesn’t calculate distance, and produces incomplete results. A plumber 0.5 miles away in ZIP 90211 doesn’t show up.

Approach 2: Haversine Formula in Application Code

Pull all listings from the database, calculate distance in JavaScript/Python using the Haversine formula, filter by radius, sort by distance. This works for 100 listings. At 10,000 listings, it’s a full table scan with O(n) math operations on every search query. Page load times climb to seconds.

The Right Approach: PostGIS

PostGIS is a spatial extension for PostgreSQL that adds geographic data types, spatial indexes, and distance functions at the database level. It uses the WGS84 geodetic model — the same coordinate system GPS satellites use — for meter-accurate distance calculations on the actual curved surface of the Earth.

How PostGIS Search Works in AI Magic Directory

Every listing location stores coordinates in a PostGIS geography column:

ALTER TABLE locations ADD COLUMN geog geography(Point, 4326);
CREATE INDEX idx_locations_geog ON locations USING GIST(geog);

When a consumer searches within a radius, the query uses ST_DWithin with a GiST spatial index:

SELECT *, ST_Distance(geog, ST_MakePoint(-118.24, 34.05)::geography) AS distance
FROM locations
WHERE ST_DWithin(geog, ST_MakePoint(-118.24, 34.05)::geography, 80467)
ORDER BY distance;

That 80467 is 50 miles in meters. The GiST index eliminates irrelevant rows before the distance calculation even runs — so performance stays constant regardless of total listing count.

Performance Comparison

Approach	100 listings	10K listings	100K listings
ZIP code match	5ms	5ms	5ms (but incomplete results)
Haversine in app	10ms	200ms	2,000ms+
PostGIS + GiST	3ms	5ms	8ms

PostGIS with spatial indexes delivers constant-time performance regardless of dataset size. The GiST index pre-filters geographically, and PostgreSQL’s query planner optimizes the execution path.

Beyond Distance: What PostGIS Enables

PostGIS doesn’t just calculate distance. It enables queries that are impossible with simple math:

• Radius search: Find all listings within X miles of a point
• Polygon search: Find listings within a custom geographic boundary (e.g., a specific neighborhood or service district)
• Nearest-N: Find the 10 closest listings to a point, regardless of radius
• Distance display: Show exact distance (“3.2 miles away”) in search results
• Service area overlap: Check if a provider’s service radius covers the searcher’s location

The Conversion Impact

Better search = more leads = more revenue. When consumers see relevant, distance-sorted results instantly:

• They trust the directory more (it clearly understands their location)
• They engage with more listings (because results are relevant)
• They submit more lead forms (because they found what they were looking for)

Directories with accurate geospatial search report 2-3x higher lead conversion rates compared to ZIP code-based systems.

Full-Text Search on Top

AI Magic Directory combines PostGIS with PostgreSQL’s native full-text search (tsvector + pg_trgm). A single API call can find “sports medicine practitioners within 25 miles of downtown LA” — geo and keyword search in one query, both hitting indexed columns.

Explore the full search capabilities →