Below applies to both CE and EE. If data storage is in RAM, both data and Primary Index are deleted, right away on delete. If data sotrage is on SSD, Primary Index (PI) is always on RAM, delete just deletes the Primary Index in RAM by default. The data on SSD is eventually overwritten by a new record. Aerospike does not “erase” data on SSD on delete. Likewise, when you update a record on SSD, it is not modified “in-situ” - the entire record is read into RAM, modified or updated and written back to a new location on the SSD. The pointers in PI are updated to point to the new location. Data in the old location is eventually overwritten by a new record.
On EE only - PI is stored on Linux shared memory instead of process RAM which gives you the ability to fastrestart a node but that aside, on EE you can delete with an available delete policy of durable-delete=true. In this case, Aerospike writes a “tombstone” - an update of the record with gen, digest and lastupdate time metadata, TTL=live-for-ever but no bins data on the SSD. This tombstone is eventually deleted by a TombRaider thread when all previous versions of the record present on the SSD have been overwritten AND a configured amount of time (default 1 day) has elapsed AND there are no ongoing migrations in the cluster.