Ubicloud: PostgreSQL stability via strict memory overcommit
Original: PostgreSQL and the OOM Killer: Why We Use Strict Memory Overcommit
Why This Matters
Demonstrates critical OS-level tuning required to run PostgreSQL reliably in managed cloud environments.
Ubicloud explains why its managed PostgreSQL service enforces strict memory overcommit settings on Linux to prevent the OOM Killer from terminating critical database processes unexpectedly.
Ubicloud published a technical blog post detailing why its managed PostgreSQL offering uses strict memory overcommit configuration on Linux hosts. By default, Linux allows memory overcommitment — allocating more virtual memory than physically available — relying on the OOM (Out-Of-Memory) Killer to terminate processes when actual memory runs short. For general-purpose workloads this is acceptable, but for PostgreSQL it poses a serious reliability risk: the OOM Killer may terminate the postmaster or a critical backend process, causing database crashes or data corruption. Ubicloud's approach sets vm.overcommit_memory=2 (strict mode), which instructs the kernel to refuse memory allocations that exceed available physical RAM plus swap. This prevents situations where PostgreSQL processes appear to succeed in allocating memory at fork time, only to be killed later when memory is actually needed. The post notes that PostgreSQL's multi-process architecture — spawning a new backend process per connection — makes it particularly vulnerable under default overcommit behavior. Strict overcommit ensures allocation failures happen early and predictably, allowing PostgreSQL to handle them gracefully rather than being killed mid-operation. Ubicloud positions this as a standard hardening practice for any production PostgreSQL deployment.