Memory and State Management
Memory Deletion — Stack
Memory deletion › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
You are choosing mechanisms whose job is to make content unrecoverable across several systems and to produce evidence of it, within a deadline.
- Removal versus marking. Whether a delete removes bytes or writes a marker, and how long the bytes survive afterwards in segments, replicas, and snapshots.
- Index purge behaviour. How a deletion propagates into approximate and inverted indexes, and whether a full rebuild is required before the content stops being retrievable.
- Subject addressability. Whether the store can enumerate everything belonging to a subject, which decides whether a broad request is computable at all.
- Backup reconciliation. Whether the backup strategy supports either excluding erased subjects on restore or re-applying erasures afterwards.
- Cascade mechanics. Whether derived and referencing items can be found and handled in the same operation, or only by a separate traversal.
- Verification. Whether the system can be queried after the fact to confirm absence, rather than only asserting that a job ran.
- Deadline predictability. Whether completion time across all systems is bounded and measurable, since the obligation has a date attached.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Direct row deletion in a transactional store (PostgreSQL, MySQL) | Primary stores where the content has a clear owning row | Bytes persist in write-ahead logs, dead tuples, and replicas until vacuum, truncation, and replication catch up |
| Tombstone plus compaction (Cassandra, LSM-based stores, Kafka with key compaction) | Distributed stores that cannot perform an immediate in-place removal | Content remains readable until compaction; tombstone lifetime is a tuning parameter that becomes a compliance parameter |
| Crypto-shredding: per-subject encryption keys destroyed on erasure (envelope encryption with a KMS) | Immutable stores, event logs, and backups that cannot be rewritten | Key management becomes the control; every copy must have been encrypted under the right key from the beginning, with no exceptions |
| Index rebuild or segment-level purge (OpenSearch delete-by-query plus force-merge, vector store collection rebuild) | Ensuring deleted content stops being retrievable rather than merely being marked | Rebuilds are expensive and disruptive; some approximate indexes retain deleted vectors in graph structure until rebuilt |
| Object lifecycle deletion with versioning disabled or versions purged (S3, GCS, Azure Blob) | Large payloads stored outside the primary database | Object versioning and soft-delete features silently retain the data; replication to another region may retain it longer |
| Orchestrated erasure workflow across systems (Temporal, Step Functions, a purpose-built privacy workflow) | Producing a per-request, per-system completion record within a deadline | Another system to operate; it must itself be resilient, and its own records are a copy of who asked for what |
| Privacy request management platforms (OneTrust, Transcend, Ethyca, DataGrail) | Organisations with many systems and a formal request intake and reporting obligation | Discovery of where content lives is still yours; the platform tracks requests, it does not know your derivation graph |