Most of the world does not run on fast lines and big budgets. We built Elara so that great routing, and the data behind it, can run anywhere: on one bar of signal, on a small server, in the towns the big maps skip. When you can serve the whole planet on thin resources, you can serve everyone.
A delivery driver in Nakuru. A fleet owner in Lagos. A family on one bar of signal on a mountain pass. They all need to get where they are going, on the phone and the network they already have. The big mapping companies answer that with more data centres. We do not believe great routing should need a data centre at all. If the whole engine can run on a small, cheap server, then cost stops being the reason a place gets left off the map. That is the point: efficiency is not a saving we keep. It is the door we open.
We do more with less in two ways, and both are ours.
We schedule our work the best way the hardware allows, and we can prove it. Not tuned by hand until it felt fast; checked by machine to be the best possible for the resources it runs on. That is why one small server keeps serving the world even when the load spikes and the upstreams slow down.
We built our own compression, ElaraShrink, and the routing engine runs on it, both ends. What we keep on the drive is stored compressed. What we send to your screen goes over the wire compressed. So the same job needs a fraction of the disk and a fraction of the bandwidth, and the saving reaches you as speed. How it works inside stays ours.
Not a slide. Measured on the live system, every byte checked by a SHA-256 round trip. The column that matters is vs raw: how much of your storage simply disappears.
| Infra file | raw | gzip | ElaraShrink | vs RAW | vs gzip |
|---|---|---|---|---|---|
| road_graph_ship.sqlite | 364.7 MB | 161.7 MB | 109.2 MB | 70% gone | +32% |
| POI gazetteers | 25.1 MB | 6.4 MB | 4.8 MB | 81% gone | +25% |
| world cities | 12.1 MB | 3.7 MB | 2.9 MB | 76% gone | +21% |
| TOTAL | 416 MB | 185 MB | 130 MB | 69% gone | +30% vs gzip |
Two thirds of the storage, gone from the raw size. A third smaller than gzip, the codec the whole industry already runs on. And it stays fast: the gazetteers decode in tens of milliseconds, the 365 MB database in about two seconds.
Elara is an infrastructure company, not only a map. The discipline that routes a van, do the most with the least and prove it, now stores and moves the data too. That is what lets one small server carry the world.
The stack: the whole site runs on AWS and Flask, sitting on our own ElaraShrink Box and ElaraShrink infrastructure. The very compression we sell carries our own engine. We run on what we ship.
Picture Dropbox or OneDrive. Now make every file inside live at a third of the size, and still open it, add to it, and pull from it the moment you ask, the way you would from any folder. You never unzip it first. The box stays compressed on the drive and behaves like a normal container, live. For a team holding terabytes, two thirds of the storage bill is gone, and nobody changes how they work.
| Dropbox / OneDrive | ElaraShrink Box | |
|---|---|---|
| Files on the drive | full size | a third of the size |
| Open a file | instant | instant, no unzip |
| Add or remove a file | live | live, no re-pack |
| The storage bill | full | cut by two thirds |
ElaraShrink compresses one file. ElaraShrink Box is the whole drive: deduplicated across every file, compressed once, worked on live.
| On the wire | gzip | ElaraShrink |
|---|---|---|
| The script on every page | 6.6 KB | 5.5 KB |
| A route sent to your screen | 3.5 KB | 2.2 KB, 37% lighter |
| Routing | ||
| A slow upstream, routed around | 3.0 s | 0.34 s, 8.8x faster |
| Under heavy load, and it stays up | 12.1 s | 6.2 s |