Ubicloud runs PostgreSQL with strict memory overcommit to avoid OOM-killer cascades

Category: Engineering post
Status: discussion
Sources: Ubicloud blog, HN discussion
Summary: A Ubicloud post dated 2026-04-27 (front page on 2026-07-03) explains why they set vm.overcommit_memory=2 for PostgreSQL. When the Linux OOM killer terminates any backend, the postmaster assumes shared memory may be corrupted and kills all backends, dropping every connection and forcing crash recovery. Strict overcommit makes the kernel return ENOMEM to a single allocation instead, so one backend fails its transaction and the postmaster stays up. They size the limit at 80 percent of physical memory plus 2 GB, which they say protects over 99 percent of their fleet, and note a one-character kernel accounting bug in 6.5 that forced them to disable the setting until the 6.8 fix.
Why it matters: It is a concrete operational recipe for turning a full PostgreSQL outage into a single failed query, relevant to anyone running Postgres on Linux without cgroup memory limits.