Skip to content

CONCEPT Cited by 1 source

Postgres memory accounting

Definition

Postgres memory accounting is the decomposition of a Postgres node's total memory usage into behaviourally-distinct categories that share a display scale but do not share meaning. Simeon Griggs (PlanetScale, 2026-03-30) canonicalises the four-category stacked chart that the PlanetScale dashboard presents:

  • Active cache — "data the OS recently touched and wants to keep around."
  • Inactive cache — data that "hasn't been accessed lately" but is still held in the page cache in case it's needed.
  • Memory-mapped — "cached pages that are backed by real files on disk."
  • RSS (Resident Set Size) — per-process memory that Postgres has allocated for work (stack, heap, catalog/relcache caches, sorts, hash tables, prepared statements).

(Source: sources/2026-04-21-planetscale-high-memory-usage-in-postgres-is-good-actually.)

The cache vs process grouping

Griggs's load-bearing reframing is that the four categories group into two use-cases:

Category Group Reclaimable? Growth meaning
Active cache Cache Yes Good — warm working set
Inactive cache Cache Yes Good — cold data still cached
Memory-mapped Cache Yes Good — file-backed reads cheap
RSS Process No Bad if sustained — memory pressure

"If total memory is high because cache is high, good! Frequently accessed data stays near the CPU for faster access. … If total memory is high because RSS is high, that is referred to as memory pressure and is a problem."

Why the single-percentage number misleads

The PlanetScale cluster-diagram widget shows a single memory percentage (e.g. 80%). On this display:

  • 80% split as 70% cache + 10% RSS = healthy — warm cache, low process pressure.
  • 80% split as 20% cache + 60% RSS = memory-pressure state — OOM risk, impending restart.

Same display, opposite interpretations. The operator's first diagnostic step is to open the stacked-chart view and decompose the 80% into its four components.

Interaction with shared_buffers

Postgres's own shared_buffers pool is part of RSS (it's allocated to the Postgres process group). The OS page cache that sits underneath is cache (reclaimable by the kernel). This creates the counter-intuitive accounting outcome that increasing shared_buffers shifts memory from the "cache" category to the "RSS" category without changing total memory use — which is exactly why Griggs discourages operators from tuning shared_buffers as their first RSS-reduction lever.

Seen in

Last updated · 550 distilled / 1,221 read