How do you troubleshoot a Weaviate collection running out of memory at scale?

An out-of-memory condition on a Weaviate node almost always traces back to the resident vector index (typically HNSW) and its associated data structures exceeding available memory, and the fix generally involves either reducing that footprint or spreading the load across more capacity.

1. Check whether compression is enabled - an uncompressed HNSW index for a large collection is the single most common cause; enabling RQ (or another quantization technique) can dramatically cut memory usage with well-retained recall.
2. Check whether HFresh is a better fit for this collection - for the largest, most memory-constrained collections, HFresh's disk-based posting lists with only a compressed centroid index in memory offer a fundamentally smaller memory footprint than HNSW, at some latency cost.
3. Check whether multi-tenant collections are using an appropriate index per tenant - confirm the Dynamic index (or explicit Flat for small tenants) is actually being used rather than forcing every tenant onto memory-heavy HNSW regardless of their individual data size.
4. Check replication factor relative to available cluster capacity - each replica is a full additional copy of the data; a replication factor that made sense at a smaller collection size may need reconsideration as the collection grows substantially.
5. Check for unnecessary named vectors - if a collection defines multiple named vectors per object but not all of them are actually used in queries, removing unused ones directly reduces the total vector data that needs to be indexed and held in memory.
6. Scale out the cluster - if the data genuinely needs to stay in an uncompressed, high-performance configuration, adding more nodes and increasing shard count spreads the same total data across more machines, each needing less memory individually.

As with similar troubleshooting in other vector databases, the right fix depends on which constraint actually binds: a workload that can tolerate somewhat higher latency benefits most from compression or HFresh's memory-efficient design, while a latency-sensitive workload that genuinely needs full in-memory HNSW performance is better served by scaling out cluster capacity instead.