Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you don’t need edge compute (which you do if you have customers dispersed geographically) then what you say is true.

But if you do no amount of Kubernetes on the old school cloud providers is going to get you there. You will encounter the hard problems fly solves for.




Do most web apps need edge compute? Don't most backends talk to a central DB server anyway?

Unless data is geographically sharded as well, is there really a benefit? Collaborative apps perhaps?


Read replica caches at the edge are pretty standard (whether the main db or a cache layer like redis).

I think the killer app on fly is actually a geo aware sql db such as cockroach. That as a managed offering puts fly above and beyond anything we’ve had before.

I suspect they know this.


Caching at the edge could be done by an API gateway or nginx.

Geo aware SQL DB sounds like a lot of added complexity. What is the latency trade off in practice? 100ms ping time is probably small compared to query execution time, especially if your backend returns everything the frontend needs in one response.

I understand someone at the scale of Amazon wanting to shave ms off page loads. But most web apps?


Well you have to run an api gateway or nginx at the edge…

The last web app I worked on had a latency budget of 200ms. The one before that it was 400.

Cross pacific queries can take 200 of that off the top. Even transcontinental is close to 80. With query times you can at least work to improve them.

Now it’s not as simple as just locality but that’s a starting point.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: