[HN Gopher] The challenges of soft delete
___________________________________________________________________
The challenges of soft delete
Author : buchanae
Score : 21 points
Date : 2026-01-20 21:36 UTC (1 hours ago)
(HTM) web link (atlas9.dev)
(TXT) w3m dump (atlas9.dev)
| cj wrote:
| We deal with soft delete in a Mongo app with hundreds of millions
| of records by simply moving the objects to a separate collection
| (table) separate from the "not deleted" data.
|
| This works well especially in cases where you don't want to waste
| CPU/memory scanning soft deleted records every time you do a
| lookup.
|
| And avoids situations where app/backend logic forgets to apply
| the "deleted: false" filter.
| vjvjvjvjghv wrote:
| I guess that works well with NoSQL. In a relational database it
| gets harder to move record out if they have relationships with
| other tables.
| tempest_ wrote:
| Eh you could implement this pretty simply with postgres table
| partitions
| nemothekid wrote:
| The trigger architecture is actually quite interesting,
| especially because cleanup is relatively cheap. As far as
| compliance goes, it's also simply to declare that "after 45 days,
| deletions are permanent" as a catch all, and then you get to keep
| restores. For example, I think (IANAL), the CCPA gives you a 45
| day buffer for right to erasure requests.
|
| Now instead of chasing down different systems and backups, you
| can simply set ensure your archival process runs regularly and
| you should be good.
| whalesalad wrote:
| A good solution here (can be) to utilize a view. The underlying
| table has soft-delete field and the view will hide rows that have
| been soft deleted. Then the application doesn't need to worry
| about this concern all over the place.
___________________________________________________________________
(page generated 2026-01-20 23:00 UTC)