Is Fly.io’s Johannesburg region good enough for Nigerian users?

Give Fly the credit it is due. Placing machines in 35 regions with anycast routing in front of them is hard, and having one of those regions in Africa at all puts Fly ahead of Render, Vercel-by-default, DigitalOcean, Netlify, Heroku and Supabase. If you are running stateless compute for African users and your state is somewhere else regardless, jnb is a good choice and you should use it.

The gap is state. Fly’s Managed Postgres is not offered in jnb, so the shape of a Fly app serving Nigeria is compute in Johannesburg and Postgres in Europe. That is worse than it sounds for a page that makes several sequential queries: the browser saves one long hop and every query gains one. Unmanaged alternatives exist — a Postgres you run yourself on a Fly Machine with a volume in jnb — and then you own the backups, the failover and the upgrades, which is the thing a managed database was for.

On distance: Lagos to Johannesburg is roughly the same as Lagos to Frankfurt in kilometres, and often worse in practice, because West African traffic to southern Africa frequently routes through Europe rather than across the continent. African internet topology is not a straight line, and the only reliable way to know what your users see is to measure from their network rather than from a map.

Residency, again, is the argument that does not bend. A requirement naming Nigeria is not met by South Africa, whatever the latency turns out to be.