[packet_mover]

No. When I looked at Photon and saw that it involves running Java plus an OpenSearch/Elasticsearch backend on the device, I assumed it would be heavier in terms of memory and moving parts than my setup (single SQLite file + small HTTP API).

Have you (or anyone here) actually run Photon on edge-class hardware? If you have real-world numbers, I'd be interested in seeing them. When I add house-number search, Photon might be an easier route than enhancing my current approach.

[karussell]

> involves running Java plus an OpenSearch/Elasticsearch backend on the device

photon is just a single process and opensearch runs inside it (but you can run photon and opensearch separately). Saying "Java" means more memory is in general wrong as the underlying technology Lucene is heavily memory optimized.

[dennis16384]

Well, trying out is better than a thousands words

Let's start it with index of whole Spain, 2.4gb download, 4gb on disk: https://gist.github.com/dkourilov/e243270684b5973f1fac005c78...

I'd say it's pretty usable to run a EU-sized country or several US states on any commodity PC. For embedded devices, it really depends what is the device. On Raspberry PI it should be fine for batch geocoding, realtime (typeahead) will definitely be lagging.

[packet_mover]

Thanks both - appreciate the clarification and the Spain datapoint.

Those numbers look pretty reasonable. I’ll keep Photon in mind and, as I get time to benchmark different approaches on a few representative regions/hardware, I’ll use the results to decide what the best way forward is - and I’ll publish the numbers when I do.