What actually gets deleted when you delete it
I sent two deletion requests in the same week last year. One came back in eleven days with a numbered list: profile gone, order history gone, invoices retained for accounting, marketing list gone, and a line saying my record would clear their backups within a year. The other has never been answered at all.
Both companies removed my live record. I checked the second one by trying to log in and by asking support to look me up. Nothing.
So the outcome was almost identical and the experience was completely different, which is roughly the shape of this entire subject.
The cynical version does the marketing version’s work
Nothing is ever really deleted, so why bother.
That line sounds like someone who has been around. What it actually does is talk people out of twenty minutes of work that measurably reduces what is held on them, and every company holding that data is delighted to hear it repeated.
I am on the operator side of this. I hold customer accounts, invoices, usage logs and a database that snapshots off site every night. When somebody asks me to delete their account I am the person deciding what goes, what stays, and what my accountant would object to.
The answer is more interesting than either of the two positions people usually take.
One word covering two jobs
When a user says delete, they mean their record stops being usable by the company.
When an engineer says delete, they mean the bytes are gone from every medium they were written to. Live database, read replica, search index, whatever caches sit in front of it, the nightly backup, the log lines from the day the row was created.
The first is routine and happens on a schedule. The second is close to impossible on demand, and the reasons have very little to do with anybody wanting to keep you.
Most arguments about deletion are two people using the same word for different operations and getting angrier.
The flag, then the job
Here is what actually happens when the button gets pressed.
Almost no production system removes a row at that moment. It writes to a column called something like deleted at, puts a timestamp in it, and every query in the application learns to skip rows that have one.
That exists because people make mistakes. Somebody closes the wrong account on Friday and phones on Monday, and one update statement fixes it. Without the flag you are restoring an entire database to undo a single click.
A scheduled job then comes along and removes the flagged rows properly. That job is the whole question. Days to a month is normal, thirty days is the figure quoted most, and on services run by people who care it is generally true.
Once it has run, the useful thing has happened, and it is worth being clear about why. The live table is the copy that gets used. It is queried, joined, exported, handed to partners, and searchable by an employee with a spare afternoon. A backup is a file that gets opened when something has gone badly wrong. Getting out of the first one removes nearly all the exposure that was actually accruing.
Nobody surgically edits a backup
My retention looks like this: nightly snapshots kept a month, a weekly kept longer, a monthly image kept for a year. Corruption introduced in February sometimes only surfaces in May, which is what the long one is for. The whole lot costs a few dollars a month in object storage.
So somebody who asked me to delete their account in January still exists inside a restore image in August. Nobody chose that. It falls out of the schedule.
And there is a hard technical reason nobody reaches into an old backup to cut one person out. A backup you have edited is no longer a backup. Its only job is to be a faithful copy of one moment. Modify it and you have a file you cannot trust to restore, which removes the reason it exists.
What a careful operator does instead is keep deletion requests in a queue and replay it after any restore. If I roll back to March, the queue runs before the service accepts logins, and the deleted person is gone again before anybody can see them.
If you ever get one technical question with a company, ask that. Do you reapply deletions after a restore. The ones who have thought about it answer immediately.
Money is kept, and it should be
If you paid a company, that payment is an accounting record before it is a personal one. It reconciles against a bank statement and it appears in a tax filing that somebody may examine years later.
I cannot delete an invoice because the person named on it asked me to. Retention duties of that kind exist in most countries and the clocks on them are measured in years.
What should happen is that the invoice narrows. Name, amount, date, what was bought. Those survive because they have to. The behavioural profile and the usage history sitting alongside them do not have to survive, and that is the part worth pushing on.
A reply saying we have retained your billing records reads like a brush off. It is the correct answer. The follow up question is what else they kept next to it.
Statistics do not contain you
The second deliberate retention is anything already turned into a number.
If your session was counted into a total, the total holds none of you. A monthly active user figure counts people without listing any of them. A median session length is a property of ten thousand sessions and says nothing retrievable about one of them.
Which means asking to be removed from a statistic is not an operation that exists. There is nothing in there to take out. You would be asking for a different number to be published.
One caveat that matters. An aggregate over a small group stops being an aggregate. A dashboard breaking salary down by department, where one department has three people in it, is publishing something close to personal facts about three people. Statisticians have minimum group sizes for this. Product dashboards mostly do not.
The copies that left before you asked
This is the thing that genuinely defeats deletion, and it is none of the above.
If a company shared or sold your record onward, that copy is a different company’s record in a different database. Your request to the first one does nothing to the second. Some markets require the message to travel down the chain. In practice the further along it goes the less anybody can tell you who holds what.
I have written separately about how that market assembles files, so I will leave it there. The part that matters here is timing. Every day a record sits somewhere is another day it can be copied, and a copy that has been taken is permanent no matter what happens to the original.
Which makes this a tap, not a cleanup
Delete early. An account you close today still leaves behind everything copied out of it over the last three years. What closing it stops is everything that would have been copied out of it over the next three.
The value is in front of you. People picture it behind them, decide it is too late, and do nothing. That single misreading is responsible for most of the inaction on this subject.
Dormant is the worst state an account can be in
An account you stopped using is in worse shape than one you closed.
It feels finished because you never open it. At the other end it is a live row holding an email address, a password you probably reused in 2019, and often a card. It goes into every export. It is in the breach when the breach comes, because dormant rows sit in the same table as active ones and nobody separates them.
Nobody is watching it either. Suspicious activity on an account you use daily eventually reaches you. Suspicious activity on the one you forgot about goes to an address you stopped reading years ago.
Full exposure, zero benefit. There is nothing else in your digital life with that ratio.
The purge job I never wrote
For about four years my own systems had a delete button that set the flag and did nothing after that.
I wrote the soft delete because I needed the undo, and I intended to write the purge job the following week. I did not write the purge job.
I found out during a database migration when the row count came out wrong. Records I believed had been gone since 2021 were sitting there with a deleted at timestamp on them. Invisible in the application. Perfectly readable to anyone with database access.
Nothing leaked and nobody acted in bad faith. Half the feature shipped and the other half stayed on a list. I suspect that describes a lot of small services. Mine purges weekly now and replays the deletion queue after a restore, and it took a migration script embarrassing me to get either written.
So: close the accounts you stopped using, oldest first, using the real deletion route rather than deleting the app off your phone. Read what comes back. The tools and services I have actually tested are here.
And stop worrying about the version of you sitting in somebody’s restore image from last March. It is real, it will age out on its own, and it was never the copy doing anything to you.