Hi everyone—first post here! I searched the forums/docs but couldn’t find a clear answer.
I’m evaluating Fly.io Managed Postgres (MPG) for a read-heavy application. I’m specifically looking for a setup like this:
Primary in one region
One (or more) read-only replicas in other regions to serve local reads
Ability to promote a replica to primary if the primary fails (manual or automatic)
I’m aware MPG handles monitoring and re-provisioning, but my question is about the read-replica/standby pattern across regions and whether replicas can be promoted.
Is this possible with the MPG service today? If yes, could you point me to the docs or outline the setup (limits, expected lag, promotion process/failover behavior, connection strings)? If not, is there a recommended approach or roadmap?
For context, I know this sort of pattern has been possible with the older Fly Postgres offering.
Hey @coocoo91, right now there is no option to create read replicas.
If I’m recalling correctly, all clusters consist of two Machines, where one is the primary and the other is a replica. The replica is there to maintain high availability, i.e. it’s just there in case it needs to be promoted to primary (in the event the primary becomes unavailable for any reason), not to act as a read replica. In fact, I don’t believe it receives any load at all, it really is just acting as a standby. Someone from MPG team may be able to confirm.
As far as leadership election, MPG automatically handles promoting the replica when necessary. That is part of the “managed” aspect of M PG.
If you absolutely need local reads to be superfast, MPG might not be the right fit.
If your app can happily handle the latency of a round-trip to the region in which you place your database, then MPG may work fine, but you might want to do some load testing to determine if there’s a CPU/mem configuration that will work for your app.
With respect to roadmap, I don’t believe read replicas is on the MPG team’s current list of priorities.
I want fast regional reads, but I can lean on NATS + KV as a localized, replicated cache instead. With Cloudflare in front, I can’t guarantee a Texas user will always hit a Texas cluster anyway. The downside is that skipping regionally replicated DBs increases my operational load.