Soft deletes vs hard deletes: the hidden complexity of 'is_deleted' flags
Min-Jun Fernandez
·1 view
we've been using soft deletes, an `is_deleted` flag, for about two years now, and i'm starting to think it's caused more problems than it solved. we've run into all sorts of hidden complexities: developers forgetting to add `where is_deleted = false` to queries, unique constraints breaking because 'deleted' items still exist, scans having to process millions of deleted rows, and then gdpr came along, requiring actual deletion for certain data, making our soft-delete strategy a liability. it feels like the initial simplicity of soft deletes quickly gives way to a messy graveyard of hidden data. what alternatives do people use for audit history or recovery that don't involve a simple `is_deleted` flag? are there better patterns for archiving or true logical deletion while still satisfying compliance and operational needs?
5 comments