Thirteen million entities. One phone. No JSON anywhere in the hot path. In May 2026 we baked a full city extract of OpenStreetMap into our own binary substrate and rendered it on an iPhone directly from the mapped bytes, with a frame loop that reads columns the way the processor wants to read them and crosses no language boundary. The city works and the measurements are below. The same campaign then pushed toward a country and the planet, and the gates it met are specific enough to be worth reading if you build spatial systems, mobile data engines or anything that has to get very large data onto a very small device.1
The city, measured
The city was Calgary: a 37 MB OpenStreetMap extract that decomposes into 12.8 million spatial nodes, 13.6 million entities and 888 thousand ways. Baked through our pipeline, it becomes 1,375 spatial cells in a memory-mapped binary format that the iPhone reader opens directly, with no parsing step and no JSON on the frame path.
| Property | Observed |
|---|---|
| Load | 1,375 cells, 1.1 GB, mapped in under a second on the simulator |
| Cell selection | A downtown viewport visits 1 of 1,375 cells |
| Emission | 5,916 shapes per frame for downtown at city zoom (641 polygons, 5,275 lines) |
| Disclosure | Level-of-detail tiers gate feature kinds and a per-kind on-screen minimum extent, so a residential street appears only when it would be at least three pixels wide |
| Verified on device | Every building shape in the city visible at street zoom; at wider zoom the sub-pixel filter correctly suppresses buildings under four pixels |
| Cold frame at city zoom | 782 ms, of which 546 ms is the cull over 190 thousand primaries in the visited cell and 225 ms is decode |
The cull cost is interesting because of how close it is to hardware. The cell's columns are sorted along a space-filling curve, so a bounding-box cull walks one column at a time in cache-friendly order and spends about 2.9 microseconds per primary, within a small factor of the processor's streaming bandwidth. The renderer reads the mapped columns directly, and the frame loop crosses no language boundary. The remaining cost is a per-cell decode cache,2 and the arithmetic says a warm repeat frame drops to tens of milliseconds, which is the difference between a demo and a map you can pan.
The bundle shrinks without architectural risk. Dropping a per-record confidence column the map does not need saves about thirty percent, and standard compression over the slim mirror gives another three times, so the city ships in roughly 235 MB.3
The gates between the city and the planet
Every one of these is recorded in the order it was met, with what was fixed and what remains.
The compressed boundary stream failed its quality gate. Our headline path for very large regions is a compressed representation of the geometry, produced by a tensor-network pipeline, from which the phone renders directly. On the city bake, the reconstruction error on the spatial stream was 185 times the target, and on the tag and reference streams the gates were effectively random, because one training parameter had been left at a default that was correct for one stream and degenerate for the others. The fix was small, was landed, and was never re-run against the city because the raw memory-mapped path rendered correctly and the campaign moved on. That decision was correct for the city demo and is the single reason the planet is not yet validated.
Bounding boxes were built from the noisy reconstruction. Before the fix, spatial noise in the compressed stream translated to bounding boxes that claimed a Calgary cell spanned continents, and viewport queries returned wrong cells. The reader now builds its index from raw geometry, and the pipeline change to do the same is queued.
Safety caps assumed a smaller city. Two in-memory caches were capped at five million entries and silently returned nothing when the city exceeded them, so every shape was classified as unknown and filtered out. Raising the caps fixed the city. At country scale those caches must become streaming, disk-backed structures, because two billion node identifiers do not fit in a phone's memory as a hash map.
Relations are not rendered yet. The format reserves columns for topology atoms and the encoder does not emit them, so multipolygons and route relations are absent. That is about two percent of features in a city and matters much more at planet scale, where borders and long routes are relations.
The country bake stalled. An EC2 stage downloading a 5.9 GB extract was interrupted mid-run, and the discipline we adopted afterwards is the useful part: lock the city recipe, implement its levers in the encoder, measure again, and only then bake a country with the locked recipe.
What the planet actually needs
The arithmetic is unforgiving. The city's raw memory-mapped bundle scales linearly, so a country is roughly 175 GB raw and a planet is far beyond any device. The compressed boundary path is the only route,4 and it depends on the quality gate that has not yet passed on the city. Even then, the per-entity identity sidecars, which the compression headline never counted, run to hundreds of gigabytes at planet scale on their own; they will need their own compression, or to stay on a server and be fetched by locality, or to be sharded by tile.
Why this belongs on a database company's Journal
Because the substrate under the map is the same one under our post-quantum stored-data work: a content-addressed atom store with an index over it, projected here as a spatial cell format the phone maps directly. The lessons are the same ones that matter for any consequential data on a constrained device. Measure the cold path before optimising the warm one. Build indexes from truth, not from reconstructions. Treat safety caps as scaling assumptions that will fail silently. And publish the gate you have not passed, because that is the number your next reader needs.
What to bring us
- A region. If you have a city or a country you need on a device with no server dependency, tell us the extract size and the device class, and we will tell you which path applies today and what it would take.
- A spatial workload that spills. If your mobile or edge system holds geometry that does not fit in memory, the memory-mapped column layout is worth a conversation.
- Your own failure list. If you have built a planet-scale pipeline, we would rather learn from yours than rediscover it.
Write to hello@8braid.com with the subject "Spatial data on device: region review". You will hear back from an engineer.
Sources and further reading
- OpenStreetMap and the Geofabrik extracts used for the city and country bakes
- 8DB: Every Number on This Site Has a Harness
- 8DB: Six Databases Is Not an Architecture
OpenStreetMap data is available under the Open Database License. iPhone is a trademark of Apple Inc. 8Braid is not affiliated with or endorsed by Apple Inc. or the OpenStreetMap Foundation.
Footnotes
-
This is a write-up from the middle of a campaign, not after its end. The country bake stalled and the planet path is not yet validated; every failure on the way is recorded in order in "The gates between the city and the planet", with what was fixed and what remains. ↩
-
The per-cell decode cache is designed and not yet built. The tens-of-milliseconds warm-frame figure is arithmetic from the measured cold frame, not a measurement. ↩
-
The two levers, dropping the confidence column and compressing the slim mirror, are measured; they are not yet flipped in the encoder. ↩
-
We will not quote a planet-scale compression ratio here. An earlier figure circulated internally from a smoke test whose scope did not include the identity sidecars, and it does not survive the arithmetic in this section. When the compressed stream passes its gate on the city and the sidecar strategy is measured, the number will appear here with its harness. Until then the honest statement is that the city works, the recipe is partly implemented, and the planet depends on a gate that is fixable and not yet passed. ↩
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work