Hi all,
Our Managed Postgres cluster in iad (Starter) has lost its primary three times since 1 Nov. We can’t confirm the cause from our side: machine status on the MPG nodes returns 401, and memory/OOM metrics for the managed nodes are not exported.
What we see (UTC):
-
2026-11-01 02:58 to 03:22: the primary became unreachable and the replica was promoted at 03:17. Plan: Basic (1 GB).
-
2026-11-01 13:51 to 13:56: the new primary became unreachable and the other node was promoted at 13:52:30. Plan: Basic.
-
2026-11-02 08:47:54: crash restart of the primary without failover (pg_bgwriter stats reset at 08:47:54, pg_up = 0 at 08:48:00, postmaster start time unchanged, backends 64 to 32). Plan: Starter (2 GB).
Our working theory is memory: per-backend caches grow to ~27 MB under our workload, and we had up to ~50 backends through PgBouncer. We have since capped the app at 25 backends, set work_mem 8 MB, hash_mem_multiplier 1, jit off and no parallel workers per session. There has been no restart since.
Questions:
-
Can someone on the Fly team check the node events and kernel log (OOM killer) for these three windows? I can share the cluster ID privately.
-
How much memory is left for backends on Starter after shared_buffers (640 MB)? Can we lower the server-level work_mem (128 MB), or is it fixed per plan?
-
Is there a read-only endpoint to the replica that the app can use for reads, and is it included in the plan?
-
Can the app connect to Postgres directly, bypassing PgBouncer? In session mode, retiring an app client does not end its server backend, so per-backend caches are only freed by PgBouncer’s server_lifetime.
-
Changing Starter to Launch: how long is the downtime during the switchover, and how is a mid-month plan change billed?
Thanks,
Paul