[beck5]

At last, an examination of the true nature of 'edge' computing is presented. Despite the appealing promises made by posts from Fly.io and others that depict 'edge' computing as a simple success, the reality can be more complex.

I have recently spent a fair bit of time experimenting with this on Fly for my application (https://www.ssrfproxy.com). It's hard to beat the straightforwardness of deploying in a single region, with the database in close proximity. This approach probably to meets the needs of what 99% of developers require. Aka Heroku.

[pier25]

Actually on Fly it's trivial to set up PG read replicas that your edge apps can read from.

[__alexs]

My suspicion has always been that edge computing was primarily offered by CDNs as away to increase utilisation of hardware rather than something there was significant customer demand for.

[benbjohnson]

LiteFS author here. I think single-node deployments are great and it's a model that fits many (or even most) apps out there. However, the two most common feature requests when I was developing Litestream were HA & replication. While most apps won't need those features, it's good to have it available as an option down the road. I've seen many devs choose Postgres or MySQL over SQLite simply because they didn't have these features. Once those are solved, edge computing is really more of a nice side effect.

I think it's also useful to consider that tools like LiteFS aren't just for your main database. We have several internal tools at Fly.io that fan out their data to other internal apps to consume so they can share data without having to build an API or worry about rate limiting.

[leafmeal]

HA?

[benbjohnson]

Sorry, I should have been more clear. HA = High Availability. Essentially, folks wanted the ability to automatically failover to a secondary node if the current primary failed.