Soft deletes vs hard deletes: the hidden complexity of 'is_deleted' flags
Sakura Voronova
·331 views
we've been using soft deletes (an `is_deleted` flag) across most of our system for the past two years, and it's become a hidden source of complexity. we constantly forget `where is_deleted = false` clauses, unique constraints get broken because 'deleted' records still exist, and our audit requirements often demand actual data purging for gdpr anyway, negating the 'easy audit' benefit. sometimes querying on deleted rows even adds overhead. i'm strongly advocating for moving away from blanket soft deletes. what are the alternative strategies people use for audit history or recovery that don't introduce this kind of pervasive complexity? perhaps a separate `_history` table or event-sourcing specific deletions?
19 comments