[danpalmer]

This was clearly not legal advice. Soft-deletes come with a lot of complexity at the application layer, more maintenance, more security risk, and require building out user data deletion processes.

Having a deleted data table is a slightly easier approach I've seen, but you still need to be aware about user and legal requirements around deleting data.

[thayne]

> Soft-deletes come with a lot of complexity at the application layer, more maintenance, more security risk, and require building out user data deletion processes.

That depends on your application and requirements. I've worked on situations where a soft delete, where any fields with sensitive customer data are overwritten with a placeholder or random data (for legal compliance reasons) was a lot simpler than doing a hard delete and leaving a bunch of dangling records with ids pointing to records that no longer exist.

And unless your data model is pretty simple, and you are ok with not having any kind of grace period before fully deleting user data, you'll probably need to build a user data deletion process either way.

[danpalmer]

That's fair, this can be an easier approach, however you do need to make sure that all fields get scrubbed, which can be hard to do as the codebase evolves over time and more fields or field semantics change. It may also leave a bunch of metadata – timestamps can be identifying, entity graphs can be identifying.

[hobs]

Exactly - there's a tension between keeping storage, performance, and cost.

Keep everything actually can make some things faster (though mostly slower) and give you a depth of information you didn't have, but has a big impact on storage and cost.

Most people pick some mix of tradeoffs - for the important things to audit keep every state change, for other ones get the backups out.