8 posts tagged with "Infrastructure"

You need to turn an address into a coordinate. That's the whole ask. The problem is that the two ways to get there both start as a project.

Rent an API and the address is now someone else's business. Every lookup is a billable request and a row of your users' home addresses leaving your infrastructure, and the free tier caps out at one request a second, so a table of any size takes days. Self-host Nominatim instead and you've signed up for PostgreSQL, an osm2pgsql import measured in hours and tens of gigabytes, and a service you run on a box you can never embed inside your own app. Either way, the thing you wanted — geocode(address) — sits on the far side of a week of setup.

The whole geocoder runs in your browser. You type an address, you get a rooftop coordinate, and no server ever sees your query — the gazetteer it resolves against is a SQLite database sitting on a CDN, and the page reads it with HTTP range requests, a few kilobytes at a time. It's a lovely trick. We were proud of it. Then we counted the requests it took to find a single city, and the number was 243.

So the questions for the day: why does looking up one name cost 243 round trips? What goes wrong when you search a database you can only read a slice at a time? And how do you get a global gazetteer — every country, region, county, and city we resolve against — down to about a dozen reads without putting a server back in the loop?

Open the demo, open your browser's network tab, and type an address. You'll watch it resolve to a rooftop coordinate — 1600 Pennsylvania Ave lands on the actual building, within about ten metres — and then you'll notice what's missing from the network tab: a request carrying your address. There isn't one. The parser ran in the page. The gazetteer it resolved against is a file on a CDN that the page read a few kilobytes at a time. The query never left your machine.

That's the pitch, and it's worth being clear about why it's unusual, because the three things the rest of the market hands you each ask you to give something up.

Our training corpus is built from source: hundreds of millions of address rows, stitched out of eleven raw data sources, written to disk over the course of a long unattended night. Last night's build ran for two and a half hours and then died on a single row. If you've ever launched a long job before bed and woken up to a stack trace instead of an artifact, you know the specific flavor of that disappointment. The questions I want to answer here: how does one row out of nearly 700 million take down hours of compute? Why, after we fixed the thing that killed it, did it crash again on the exact same row? And what do you change once you've learned that a correct assertion and a safe one are different animals?

The v0.5.0-a1 tokenizer was trained exclusively on US and French addresses. When it encountered Chinese, Japanese, Korean, Thai, or Arabic text, it fell back to encoding individual bytes — 50-75% of tokens for CJK scripts. Every byte-fallback token is a lost opportunity for the model to learn meaningful subword patterns.

Today we fixed that.

The /demo page now loads a 9 MB FST (finite-state transducer) gazetteer alongside the 29 MB ONNX model. 94,000 US admin places with Wikipedia importance scores feed directly into the neural classifier's Viterbi decoder as emission priors — the same pipeline that runs server-side now runs entirely in the browser.

We shipped a browser-based address parser that runs a 29 MB ONNX model entirely client-side. The Playwright tests showed perfect results. Chrome desktop looked great. Then someone opened it on an iPhone.

The second night shift ran from roughly 2am to 2pm UTC on May 25th, 2026. It started with a GPU that wouldn't stop crashing and ended with a trained model, an ONNX export, and a full evaluation report. This is the story of how infrastructure choices turned a hardware problem into a non-issue.