[samwillis]

I disagree, any post about Heroku or any of the startups aiming to replace it (Fly or Railway for example) always mention it. From the perspective of someone looking to move to one of them from Heroku:

- Render is closest to what Heroku do, however being on their own hardware they can undercut Heroku who, by running on top of AWS, are both limited but apparently also don’t want to compete on price.

- Fly is both aiming to be a Heroku alternative but also have a really compelling use case of placing many smaller VMs closer to your customers. I believe they are heading towards a target of scale to zero on distributed VM regions for your app. They have some super clever ideas around distributed DB read replicas.

- Railway I think is somewhere in the middle, but I can’t understand their pricing… they say “you only pay for what you use” and the pricing page imply a that you can use fractional resources. It seems confusing as to if they have some sort of auto scale to zero or not. The docs are lacking on in the regard.

For me Fly I think are winning. Probably with Supabase or or Crunchy Data for the DB.

[tiltrus]

Render.com has been a lot more stable for me than Fly.io. After 3-4 months of running into issues running on Fly.io, I went with Render.com and have had no issues so far.

I think Fly.io employees are a lot more active on HN which is why you see them mentioned more often. They also write great blog posts which get a lot of attention here.

I also agree with the sibling comment. I came to Fly.io being sold on servers running close to the users. But I didn't see much of a peformance improvement with my web apps as they all have to communicate with Firebase. There's probably situations where this technology makes sense, but I haven't found a use case yet.

[detaro]

Curious what kind of issues you've seen with fly.io? (Most reports about them I've seen seem to be based on people trying it out relatively briefly, where they might miss things that crop up over a longer time)

[jayp]

If you are going to use a centralize database coupled with edge compute, you may end up with far worse end-to-end latencies if your compute<->db does multiple roundtrips per request (which is fairly common in practice). In most cases, you need compute and db to be colocated.

I am skeptical of edge compute being generalizable. I do forsee a bright future for it for embarrassingly parallel problem space, where data sharding can be done cleanly based on an end user.