SERVER_ERROR: No space for new record under concurrent Aerospike namespace writes

Goal

Determine whether intermittent "SERVER_ERROR: No space for new record" during concurrent writes reflects true namespace storage exhaustion or a write-path configuration issue such as key-hash hotspots or queue depth.

Constraints and uncertainty

Aerospike namespaces reject writes when storage is exhausted, but concurrent-write latency can also arise from MurmurHash3 distribution or single- versus multi-queue write paths. Adopting a custom hash would require re-hashing existing keys and validating client-library compatibility. Current documentation does not recommend a specific hash strategy for production clusters experiencing concurrent-write latency, and it is unclear whether the error can appear before the namespace is physically full.

Questions

• What hash or write-queue configuration should be evaluated first to separate storage exhaustion from concurrent-write hotspots?
• Are custom key-hash functions supported across current Aerospike client libraries without breaking existing records?
• Which write-queue setting suits mixed read-write workloads without altering durability guarantees?