How would this slow down the node’s start-up time. Cold-start-empty doesn’t read the disks when starting meaning that if Aerospike has to perform a Cold-Start (which is the only form of starting in the Community Edition) then it will come up empty. You couldn’t hope to start faster ;).
The cold-start-empty option isn’t as viable of a solution on community because the community edition does not support Fast Restart which is an Enterprise feature.
Yes, deletes only delete the 64 byte in-memory index entry. It wouldn’t help to do a write to disk unless we also tracked that delete in memory as a tombstone.
Also why would you say tombstoning is an insecure workaround? Of the workarounds it is the most robust IMO, but comes with operations hurdles.
Currently the only reliable delete in Aerospike is expiration where the TTLs of all records have never been reduced. If a record expires in this way, it does not come back. Deletes have been a long running hot topic in Aerospike and there is a lot of momentum to resolve this issue, but we refuse to compromise performance, scalability, or ease of operations for deletes. Many of our users have confronted this very problem and many of those eventually found that they could use the expiration system and achieve a better workflow.
Perhaps if you discussed your current architecture requiring deletes someone may be able to point out an alternative?