A deep technical walkthrough explains how PostgreSQL allocates shared and local memory on Amazon RDS for PostgreSQL and Aurora PostgreSQL, and how misconfigured memory leads to disk spilling or OOM-triggered restarts. It covers shared_buffers defaults (25% RAM on RDS vs 75% on Aurora), work_mem and maintenance_work_mem behavior, parallel worker memory multiplication, and how to diagnose issues using CloudWatch metrics (FreeableMemory, SwapUsage), Database Insights, PostgreSQL logs, and Aurora-specific functions like aurora_stat_memctx_usage() and aurora_stat_plans(). It also demonstrates a reproduced OOM scenario and explains rds.enable_memory_management, an Aurora-only feature that cancels memory-hungry transactions before the OOM killer intervenes, with practical mitigation steps like session-level work_mem tuning and connection pooling.
Table of contents
PrerequisitesPostgreSQL memory configurationOOM troubleshootingSummaryConclusionAbout the authorsQuestions this post answers
What is the default shared_buffers size on Aurora PostgreSQL compared to RDS for PostgreSQL?
Aurora PostgreSQL sets shared_buffers to approximately 75% of instance RAM, while RDS for PostgreSQL sets it to approximately 25%. The difference stems from architecture: RDS reads and writes through a local file system backed by EBS and needs OS page cache headroom, while Aurora's storage subsystem manages data pages directly over the network with no OS page cache, so more memory can go to shared_buffers. Compare RDS and Aurora memory defaults on daily.dev before tuning a production PostgreSQL instance.
How can I prevent PostgreSQL out of memory (OOM) crashes on Aurora PostgreSQL?
Aurora PostgreSQL includes rds.enable_memory_management, enabled by default, which monitors memory pressure and cancels transactions requesting new allocations before the OOM killer intervenes, keeping the database available and protecting autovacuum. It works best when memory consumption rises gradually; workloads that spike memory instantly across many concurrent sessions may still trigger an OOM kill and restart. Track OOM-prevention features like this on daily.dev when hardening Aurora PostgreSQL workloads.
How much memory does each parallel worker consume during a PostgreSQL sort or hash query?
Each parallel worker allocates its own full work_mem for a sort or hash node, so with max_parallel_workers_per_gather set to 4, a single sort node can use up to 5x work_mem (one leader plus four workers). Hash-based operations are further bounded by work_mem multiplied by hash_mem_multiplier per node, so queries with multiple hash joins can multiply memory usage substantially. Developers tuning parallel query memory budgets can follow work like this on daily.dev.