Account deletion removes your access and usually your profile. It does not reach backups, derived data, systems that already copied the record, or the conclusions drawn from it. What actually happens after the confirmation dialogue, and the one case where deletion genuinely works.
What the button does
It works, as far as it goes. Your credentials stop functioning. The visible profile disappears from the service and, in time, from search results.
For most people that is the thing they wanted, and it would be wrong to treat it as theatre. The account is genuinely closed. What has ended is your participation, which is not the same as the data's existence, and the interface gives no way to tell the two apart.
Where the copies are
This is engineering rather than deceit, which is why it does not yield to indignation.
Backups exist on a rotation and are deliberately immutable — that property is what makes them useful when a database is lost. Editing one to remove a single person would mean restoring it, altering it, and writing it back, which breaks the guarantee the backup was made to provide.
Replicas sit in several regions so the service survives losing one. Caches hold recent copies because fetching everything twice is wasteful. Analytics pipelines copied the row when it was written, into systems with their own lifecycles. Partners received data under agreements while the account was live, and those agreements do not evaporate when you close it.
Deleting the original does not chase the copies, because copying was the point of making them.
Derived data is the part that does not go
The distinction that matters most, and the one least often explained.
Your posts are data. The model of your interests assembled from them is derived. Removing the posts does not un-learn the model, any more than burning a textbook removes what was read from it.
A profile that concluded you are interested in a subject does not revert when the items that suggested it are deleted. And the derivative is frequently the valuable part — the raw records were only ever the route to it.
Soft delete, and why it exists
Most systems flag a record rather than remove it. Restoration after a mistaken deletion, fraud investigation, dispute handling, and obligations to retain for a period all depend on the row still being there.
Much of that is reasonable. The consequence is that deleted and gone are different states which look identical from the outside, and no part of the interface distinguishes them.
What actually shortens the tail
Delete content before closing the account. Individual removals travel through the ordinary deletion paths; closing the account is a single event that may only detach you from records that persist.
Ask what is held before asking for erasure, using whatever access right applies where you live — what is a legal question rather than a technical one, and the answer differs by place. Seeing the inventory tells you what you are actually asking about.
And supply less at the outset, which is the only measure that works reliably, because it is the only one that does not depend on somebody else's cooperation afterwards.
The one place deletion genuinely works
Where the provider holds ciphertext and you hold the key.
Destroy the key and the plaintext is gone everywhere the ciphertext exists — active storage, replicas, and the immutable backups nobody could have edited. Nothing has to be found, enumerated, or trusted to have been erased.
This is the exception that proves the rule. Deletion is reliable exactly when it is a cryptographic fact rather than an administrative promise, and unreliable the rest of the time for the same reason.
Close
Treat deletion as a request rather than an event. It reduces exposure, sometimes considerably, and it does not return you to the state you were in before you signed up. That state was left behind at sign-up, not at deletion.