layout: doc lang: en translation_key: postgresql-caching title: PostgreSQL caching decision guide seo_title: “PostgreSQL Caching Decision Guide: Pages, Rows, Views, or Redis” description: Compare PostgreSQL page caching, prepared SQL, whole-row caching, materialized views, and Redis by the work each read path avoids. section: Guides permalink: /docs/postgresql-caching.html
last_modified_at: “2026-10-04”
PostgreSQL caching decision guide {#postgresql-caching-decision-guide}
This guide compares PostgreSQL page caching, prepared SQL, whole-row caching, materialized views, and Redis by the work each option avoids.
Start with the work you repeat {#start-with-the-work-you-repeat}
| Need | Option | Work avoided |
|---|---|---|
| Keep table and index pages hot | PostgreSQL shared_buffers and OS cache |
Fewer storage reads; SQL still runs |
| Send the same statement many times | Prepared statement | Less repeated parse and plan work; execution still runs |
| Read complete rows by primary key | Authenticated RESP MGET with pg_local_cache |
Reuses eligible whole-row JSON |
| Reuse joins or aggregates | Materialized view | Reads persisted results; refresh defines freshness |
| Share application objects across services | Redis cache-aside | Application-managed keys, TTLs, and invalidation |
Pages and prepared SQL {#pages-and-prepared-sql}
shared_buffers caches database pages, not final SELECT results. PostgreSQL still checks visibility, executes the query, and builds each result. A prepared statement reduces repeated parsing; it still executes against current database state.
See row cache vs shared_buffers for work remaining on each path.
Whole rows by primary key {#whole-rows-by-primary-key}
pg_local_cache stores complete rows in bounded PostgreSQL shared memory. An authenticated RESP MGET can return an eligible cached row; ordinary SQL never reads this cache. Misses and ineligible reads use the source table. The endpoint uses one configured database role and does not share the caller’s SQL transaction or snapshot. See the batch guide, technical reference, and invalidation guide.
Views and external caches {#views-and-external-caches}
A PostgreSQL materialized view stores a query result and refreshes on demand. It suits reports and aggregates where refresh time defines freshness.
Redis suits application objects shared across processes. The application owns keys, serialization, TTLs, and invalidation. See PostgreSQL and Redis cache-aside. Run the quickstart to try the row-cache path.