The 32GB Heap Ceiling That Caps Every ES Node
JVM compressed ordinary object pointers (OOPs) stop working somewhere around 32GB of heap, so no matter how much RAM a node has, Elasticsearch and OpenSearch heap should never be pushed past roughly 31GB — this calculator hard-caps heapPerNode at 31 and turns the result red once you hit it. Required heap is derived from disk data using the standard rule of 1GB of heap per 20GB of data on disk (totalStorageRequired / 20), then divided across dataNodesRequired to get heap per node.
Where the Storage Multiplier Comes From
Raw ingest × retention understates your real disk requirement by a wide margin once three layers are applied: a 1.2x overhead factor for Lucene's index structures and field mappings, a full extra copy of storage per replica, and a 1.15x reserve modeling the default disk watermark headroom Elasticsearch keeps free so a node doesn't hit flood_stage mid-write. Combined, a single-replica cluster needs roughly 1.4x the raw ingested-and-retained data in usable disk, not 1x.
Practical Implications
- Replicas aren't free insurance: each additional replica directly multiplies both the disk and heap requirements computed here, not just your fault tolerance.
- The fix for a red heap warning is more nodes, not bigger ones: once a node's heap would need to exceed 31GB, adding RAM to that node stops helping — you need to shard across additional nodes instead.
- Sizing below assumes 2x heap in RAM per node: the cost estimate allocates 4 vCPU and RAM equal to 2x heap per node, since the OS page cache needs roughly as much memory as the JVM heap itself to keep hot segments off disk.