The idea of having to do my own upgrades by updating the docker container scares me.
I have literally never run a stateful service off docker and don’t see the point, thanks to AWS.
RDS has been extremely stable and boring. Maybe it’s out together by similar duct tape under the hood but it’s been incredibly solid for nearly a decade across multiple database stacks.
If Fly builds it, it will create another Goliath who tries to eat everything.
Servers sitting less than 1km to each other tend to have lesser latency between them, compared to servers that could be anywhere on the public internet.
But if you have a zero-trust architecture and everything communicates over wireguard, then technically public or private won't matter right?
Not saying public/private IPs don't matter – since almost all the servers would still only have private IPs.
In a sense this is more like VPC peering.
I remember a failure of one transatlantic line that was used for one direction of packets we were sending between EU and US. I spent a night on a phone trying to convince AWS and our other datacenter operator to work around the problem by changing their routing and to push the backbone operator to fix the problem - we didn't have any relationship with the backbone of course.
You don't want such disruption to happen in a core part of your app. These disruptions can also be intermittent and "random" and you have no way to fix.
I think I know what you're getting at, and if I'm right, this isn't really a subjective or squishy subject.
The only reason I think we might not be is the selling point is less vendor lock-in, not something managed significantly better. For the most part, the major cloud providers have mature, feature rich product offerings for common use cases like DB, distributed queues, running services, load balancers, etc.
A lack of integrated security and authorization? Should be solvable though.
The expense of external traffic? The latency to a DB in a different datacenter?
With Fly.io (at least today), this isn't as straightforward given your favorite database is likely not deployed there.
Higher database round-trip times are fixed by using database stored procedures instead of making multitudes of tiny compound SQL queries.
I’d be happy if they can wrap Neon’s serverless postgres service into their networks somehow.
We are working on becoming first party service on several major problems now. We will be happy to provide this for Fly. Kurt and I have been chatting.
Fly wants cross region replication which is coming soon. Once it's there we can integrate.
With that Neon is still on AWS and can be close to Fly, but not run on Fly servers. It's relatively straightforward for us to run on Fly, but the S3 part will still be Amazon.
For those out-of-loop: https://news.ycombinator.com/item?id=7382151
The best option I could find was using Digital Ocean Managed Databases. The cheapest costs $15, but you can host multiple databases with good insights and backups. You can choose where you host it, and place it close to the region where youre Fly.io apps are, with low latency.
Only caveat is there isn't an easy way to automatically update the IPs whitelist of the database, to support the Fly builder and deployed app(s).