shared_buffers: Why 25% of RAM Is Only Half the Story

Set shared_buffers to 25% of RAM — you've heard it a thousand times. But why not 50%? Why not more? The answer lies in something most people miss: Postgres isn't the only thing caching your data. The OS page cache sits underneath, holding its own copy of every block Postgres reads. You end up with double-buffering, and understanding that changes how you think about memory tuning. This video walks through how Postgres and the operating system split caching work, when the 25% rule makes sense and when it doesn't, and how different workloads (OLTP vs analytics, on-premise vs RDS) need different splits. You'll also learn how to use pg_buffercache to see exactly what's resident in shared_buffers right now — which tables, which indexes, and whether you're thrashing or sitting on headroom. For database engineers tuning Postgres in production, SREs trying to understand memory pressure, and anyone who wants to stop cargo-culting the 25% rule and actually understand what's happening under the hood. Chapters: 0:00 Intro 0:40 The Double-Buffering Architecture 3:32 When Bigger Helps, When It Hurts 5:50 Reading pg_buffercache 9:17 Practical Tuning Strategy 11:30 Get a free health report Free weekly PostgreSQL health report → https://mydba.dev?utm_source=youtube&utm_m... #postgresql #database #performance #tuning