Why soft deletion comes with a higher price than you might think.

Thoughtbot's platform is a central hub for software developers and product designers, offering insights into product development, design thinking, and agile methodologies. Through articles, case studies, and design sprints, Thoughtbot offers insights into user research, prototyping, and usability testing. Readers can learn about lean product development, iterative design processes, and cross-functional collaboration to create user-centric digital products and services.

thoughbot

Soft deletion marks records as deleted without removing them from the database, preserving data for recovery and compliance. However, it introduces significant complexity including the need to consistently exclude deleted records from queries, handle dependent record deletion properly, update indexes and constraints, and manage potential conflicts during restoration. The author suggests evaluating alternatives like better backups, improved UI design, or accepting the tradeoffs based on specific business needs rather than implementing soft deletion by default.

The hard truth about soft deletion

TLDR; another article that juniors will share at meetings saying “soft delete is bad look it’s written on the internet”
With all my respect, soft delete is widely used and is good practice. DELETE has a cost, side effects and is slow (i.e. on postgres it might trigger auto vaccums, impacts indexes, etc.)
Marking rows as deleted is cheap and fast. And can be deleted later on in a batch process during night eventually.
And the arg about &quot;if someone goes into the database and write raw SQL queries and forget to add WHERE is_deleted IS false… well dude welcome to IT.
I can also arg: IF someone goes to the db and write DELETE and forget WHERE id= he might delete a lot of rows. (be careful when you play with data)

It’s not that much of a problem to pay attention to this, in fact most frameworks specifically support soft deletion. Personally, I always use this, even if I have periodic backups of the database.

Soft delete is only the first part of the equation, and if it’s the only thing you do, your database can become bloated.
You also need a good archive strategy. What this looks like depends on the business and things like compliance / audit requirements. It could be a script that runs once a week and just hard deletes data that was deleted over a week ago, or it could also involve exporting the deleted data to a WORM storage before deleting.
And lastly, you need a tested and trusted backup solution.