When More RAM Isn’t the Fix: A PostgreSQL Performance Story
How more memory fixed one PostgreSQL bottleneck and exposed the application problem hiding behind it.
We quadrupled a PostgreSQL database server's RAM from 8 GB to 32 GB.
The diagnosis pointed to memory pressure. The buffer cache at 8 GB could not hold the working set. Increasing the RAM was the logical first step before touching any code.
The overnight results confirmed the diagnosis — and revealed something we did not expect.
Immediately, the I/O bottleneck vanished.
82% of our slow query patterns disappeared entirely from the logs.
Materialized view refresh times dropped by 75%.
The mechanics were straightforward: with the working set fully cached, queries stopped waiting for disk and ran entirely from memory.
But the upgrade did something else.
It stripped away the I/O noise and exposed our actual technical debt.
Our heaviest batch process—running 70 times a day—saw only a 22% improvement in database execution time.
The takeaway was clear.
Hardware upgrades solve I/O limitations, but they do not fix algorithmic flaws.
Adding memory only helps at the margins when the execution plan itself is inefficient.
You cannot vertical-scale your way out of a bad query plan.
Scaling vertically clears the hardware friction so you can see exactly where software optimization is required.