July 3, 2026
RAM-bo: First Blood for Databases
PostgreSQL and the OOM Killer: Why You Must Use Strict Memory Overcommit
Postgres fans say one tiny memory setting can save your database from a full meltdown
TLDR: The article says a stricter Linux memory setting can stop PostgreSQL from suffering a server-wide crash when memory runs out. Commenters mostly agree the risk is real, but they’re split between “this saved us” and “test very carefully or you’ll trade one disaster for another.”
A routine database tuning post somehow turned into a full-on comment section therapy session about computers running out of memory and taking everyone down with them. The article’s big claim is simple: if you let Linux promise more memory than the machine can really handle, your PostgreSQL database can get hit by the dreaded out-of-memory killer—which doesn’t just swat one process, but can trigger a chain reaction that drops every connection and forces a crash recovery. Translation: one memory panic can become a site-wide drama.
And the community absolutely had thoughts. One camp was basically yelling, “Yes, do this now!” with users saying they’re sick of “random programs being killed” and calling strict limits a sanity-saving move. Another camp slammed the brakes. Bender’s warning had big horror-movie energy: be careful, test everything, because the “fix” can stop programs from starting at all. Then came the real workplace chaos confessions—like one commenter who said their company put the app and the database on the same machine, switched the setting, and then watched the system become unstable in a whole new way. Classic tech plot twist.
The spiciest moment? Even someone from Ubicloud popped in to say the title may have come on a little too strong. That only fueled the vibe: great advice for managed database operators, maybe not a universal commandment for everyone else. Meanwhile, another commenter delivered the cleanest takeaway of the thread: if your database is mission-critical, stop making it share a room with chaotic roommates.
Key Points
- •The article says PostgreSQL operators used strict memory overcommit across five managed PostgreSQL services over 15 years.
- •It explains that Linux overcommit can allow memory allocations to succeed until physical memory is exhausted, at which point the OOM killer may terminate a process.
- •The article states that an OOM-killed PostgreSQL backend can leave shared memory inconsistent, prompting the postmaster to shut down all backends and trigger crash recovery.
- •It compares Linux overcommit modes 0, 1, and 2, presenting mode 2 as a way to fail allocation requests early instead of risking OOM kills later.
- •The article says the team derived a heuristic for the commit limit and references an 80% threshold plus an extra 2 GB reserve, alongside a kernel bug investigation that temporarily changed the setting.