February 12, 2026
Cache me if you can
Three Cache Layers Between Select and Disk
2 a.m. database meltdown: tune Postgres or blame the cloud
TLDR: A late-night deep dive explains how Postgres reads data through two memory caches before hitting slow, capped cloud storage. Commenters erupted over bare metal vs. containers, “used” memory confusion, and vendor opacity—agreeing that knowing these layers can save apps (and sleep) when performance tanks.
A sleep-deprived engineer poked the bear at 2 a.m., tracing a slow Postgres query through three “secret” layers of memory—Postgres’ own cache, the operating system’s cache, and finally the actual disk on Heroku riding AWS EBS. The big reveal? If the first two caches miss, you hit the disk and burn IOPS (reads per second). Hit that cap and your app crawls. Cue the comments: the thread split like a season finale. One camp cheered the explainer and shouted, “Don’t panic when Linux says memory is ‘used’—it’s caching on purpose!” Another camp side-eyed managed platforms: great until you need to know what the hardware is doing and can’t peek under the hood.
The spiciest subplot: bare metal vs containers. As one user hinted, caching is a no-brainer on a dedicated machine, but in containers or multi-tenant setups, that “free” memory may not be so free. Meanwhile, veterans showed up with war stories about vendors playing games with memory accounting—page cache counted, then not counted, then “fixed” back again. The memes wrote themselves: “free -h panic,” “RAM hoarders anonymous,” and the eternal drive-by, “Just add Redis.”
Underneath the drama, a simple truth: more Postgres cache means less OS cache, and starving either can hurt. The crowd agreed on one thing: understand the layers, or enjoy your next 2 a.m. wake-up call. Bonus homework: read Postgres docs and watch those EBS burst credits
Key Points
- •PostgreSQL reads traverse three layers: shared buffers, the OS page cache, and disk, each with different costs.
- •Shared buffers (configured at 4GB in the example) are PostgreSQL’s in-process cache; sizing guidance is about 25% of RAM.
- •Linux’s OS page cache serves reads from memory on shared buffer misses and competes with shared buffers for RAM, affecting performance.
- •If neither cache has the page, reads go to disk; on Heroku this is AWS EBS with 3,000 provisioned IOPS and burst credits observed at 3,668 IOPS.
- •Managed environments like Heroku limit visibility into physical storage; the article demonstrates inspecting a table’s on-disk page via pg_relation_filepath and hexdump.