Weaviate Out of Memory (OOM Killed)

How to fix it

Try these in order — the most common fix is first.

1. 1. Cap the Go runtime

   Copy steps
   1. Set GOMEMLIMIT to roughly 80-90% of the memory available to Weaviate
   2. Or set LIMIT_RESOURCES=true so Weaviate uses about 80% of memory
   3. Restart Weaviate and re-run the import
   Did this fix it? Yes No

2. 2. Reduce the vector footprint

   Copy steps
   1. Enable Product Quantization (PQ) and test recall on your data
   2. Use a lower-dimension embedding model
   3. Lower maxConnections and raise efConstruction or ef to compensate
   Did this fix it? Yes No

3. 3. Add resources or slow the import

   Copy steps
   1. Increase memory and CPU for the node
   2. Use dynamic batch sizing in the Python client
   3. Spread load across more nodes
   Did this fix it? Yes No

Symptoms

The container or pod restarts with OOMKilled, memory climbs to 100%, often during bulk imports.

Why it happens

• Memory needed is about 2x the footprint of all vectors (vectors x dimensions x 4 bytes)
• Very fast imports allocate memory faster than garbage collection frees it
• No memory limit set for the Go runtime
• Not enough RAM or CPU for the workload

This guide also covers

• weaviate out of memory
• weaviate oomkilled
• weaviate memory usage
• weaviate high memory

The same problem in other apps

All slow, laggy or resource-hungry guides →

• Qdrant Out of Memory (OOMKilled / High RAM Usage) (Qdrant)
• Milvus Query Node Out of Memory (OOM) (Milvus)
• Elasticsearch High JVM Memory Pressure and Out of Memory (Elasticsearch)

Other Weaviate errors

• Weaviate Error: Vector Lengths Don't Match
• Weaviate gRPC Deadline Exceeded Error
• Weaviate Batch Import Errors and Failed Objects
• Weaviate 'Memory Pressure: Cannot Init Shard' Error
• Weaviate RAFT Heartbeat Timeout and Leader Elections
• Weaviate Stuck on 'Schema Catching Up' at Startup
• How to Cancel Weaviate Cloud and Avoid Charges