Skip to content
DBRaven
Relationship · Benefits From
read heavy apiBenefits Frommaterialized view
Source: Workload·Target: Pattern

Summary

Read-heavy API workloads whose reads are dominated by an expensive aggregation, join, or computed summary — rather than a plain point lookup — benefit from a materialized view: the expensive query runs once per refresh interval instead of once per request, and every concurrent reader shares the same pre-computed result.

Evidence

  • ·read_heavy_api's summary names 'cached aggregation access patterns' as typical of the workload (workloads/read_heavy_api.yaml)
  • ·materialized_view's applicable_when condition is an expensive query (>100ms) executed by many concurrent users with infrequently changing data — a description that matches an aggregation-heavy read_heavy_api deployment (patterns/materialized_view.yaml)

Operational Context

  • ·Preferred over cache_aside when the read is the output of a genuinely expensive query (multi-table join, aggregate) rather than a cheap point lookup — cache-aside still pays that query cost on every miss, while a materialized view pays it once per refresh regardless of read volume
  • ·Preferred over read_replica when the cost driver is query complexity, not raw read volume — a replica still executes the same expensive query, just on a different node, while a materialized view avoids re-executing it at all

Tradeoffs

  • ·Introduces a refresh-lock risk (a non-concurrent PostgreSQL refresh blocks all reads on the view for its full duration) that neither cache_aside nor read_replica present
  • ·Staleness is bounded from below by refresh duration, not by a configurable TTL — a materialized view over a large table cannot be made fresher than its refresh time allows, unlike cache_aside's independently tunable TTL

Evidence grounding

Grounded, 2 supporting items

read_heavy_api's summary explicitly names "cached aggregation access patterns" as typical (workloads/read_heavy_api.yaml), which is materialized_view's exact applicable_when condition, but read_heavy_api's recommended_patterns list names cache_aside directly and materialized_view only implicitly, so this relationship is held at slightly lower confidence than the direct cache_aside recommendation pending an explicit update to that list.