Following this thread closely. I have a similar decision coming up for a MQTT broker deployment. Latency matters for pub/sub responsiveness.
From my testing in Toronto:
US-East obvious for North America. But I have European IoT devices too. Thinking of bridging two brokers rather than picking one.
Has anyone run Mosquitto or VerneMQ across regions? How bad is the bridge latency in practice?
Don't. MQTT bridges with latency >50ms get weird with QoS 1/2 handshakes. You end up with message duplication or head-of-line blocking.
Run two independent brokers, shard by device location. Accept that a device in EU talking to a device in US has 100ms+ latency between brokers. If that's unacceptable, you need a single broker and accept latency for the far devices.
There's no magic solution. Physics wins.
This. I white-label hosting for clients who don't understand why their Toronto office can't get <10ms to a server in Vancouver. I show them the speed of light calculation, they nod, they still complain.
My solution: set expectations in the contract. "Response times under 100ms for users in North America." Then put the server in Chicago and hope.
Vultr Chicago is $5, Vultr Toronto is $5, latency between them is 15ms. I pick based on client superstition about data residency.
Member OP
Good practical advice. I'm going to close the loop on my original question.
Final setup I'm implementing:
Total $25 now, $31 later. Weighted average latency to origin: 78ms for current user base (60% US, 25% EU, 10% APAC, 5% other). Acceptable.
Thanks all for the data and reality checks. CSV link is live.
Did you test Hostinger at all? They have Singapore and Mumbai now, might be cheaper than Vultr for APAC expansion.
