How We Built a 120,000 Feature Gazetteer on the Edge
Cloudflare D1, edge search, and zero cold starts—the technical story behind the Alaska Master Gazetteer.
The Alaska Master Gazetteer indexes 120,000+ locations—GNIS, DNR infrastructure, bush names, historic features. The challenge: serve fast, typo-tolerant search from the edge, with no dedicated servers.
The Stack
- Cloudflare D1: SQLite at the edge. The gazetteer lives in a single D1 database, replicated globally.
- Full-text search: FTS5 for typo-tolerant querying. "Anchorage" finds "Anchorage", "Anchorage International", etc.
- Workers: API endpoints run as Cloudflare Workers. No cold starts. Sub-50ms p99 for simple queries.
- Caching: KV for hot queries. Many lookups never hit D1.
Design Decisions
Why D1? SQLite at the edge is perfect for read-heavy, moderately-sized datasets. 120k rows is trivial. We get ACID, indexes, and full-text search without managing a Postgres cluster.
Why FTS5? Phrase search, prefix search, and ranked results out of the box. We could add Trigram for fuzzier matching later.
Why not Algolia/Meilisearch? We wanted zero vendor lock-in and to own the data pipeline. D1 + Workers keeps everything in the Cloudflare ecosystem we're already using for R2, KV, and caching.
What's Next
- Fuzzy matching for bush names and common misspellings
- Category filters (peaks, streams, mines, etc.)
- Bounding-box queries for map viewport search
- Integration with the app search bar (replacing client-side stubs)