Soft delete sounds simple: add <code>deletedAt</code> and hide the record.
Then the real questions arrive:
<ul>
<li>Can its unique value be reused?</li>
<li>Should deleted relationships still appear?</li>
<li>Can the record be restored safely?</li>
<li>Does “deleted” satisfy privacy requirements?</li>
<li>Will every query apply the correct filter?</li>
</ul>
Soft delete is a data-lifecycle decision, not just a decorator.
Without clear rules, your database slowly fills with ghosts that still affect production logic.
When do you choose hard delete instead?
#NestJS #TypeORM #DataDesign

Laughing Face

Welcome to the NestJS Developers Hub, a collaborative community for developers passionate about NestJS! Whether you're a seasoned expert or just getting started, this group is dedicated to sharing knowledge, solving problems, and advancing our skills

Nestjs Developers

Soft delete is more than adding a `deletedAt` column — it requires deliberate decisions about unique value reuse, relationship visibility, safe restoration, privacy compliance, and consistent query filtering. Without clear rules, deleted records become ghosts that silently affect production logic. The post frames soft delete as a data-lifecycle decision and raises the question of when hard delete is the better choice.

Day 11/30 — Soft Delete with Care

It depends on kind of data. As a developer of messenger software we do that:
<ol>
<li>
if user deletes messages - hard delete
</li>
<li>
if user deletes content - video or file or image - soft delete when scheduled hard delete
</li>
<li>
if something deleted from admin panel then moving to archive warehouse.
</li>
</ol>

Good Things brother.
Thank you for sharing.

Soft delete is easy to implement, but hard to maintain. If restoration or auditing isn’t a requirement, hard delete often keeps the data model much simpler.

But what is the article about? Soft deletes are complex due to the relations and constraints within each piece of software and database/ORM. They are really hard to maintain if you don’t take them into account from the beginning.

The uniqueness and retention rules are where soft delete stops being a small schema change. I like defining restore, purge, and legal-retention behavior first, then designing indexes and queries around those rules so deleted rows cannot quietly affect production logic.