> The application ORM layer usually automatically filters out "deleted" records, but this convenience can lead to oversight when constructing complex SQL querie

> The application ORM layer usually automatically filters out "deleted" records, but this convenience can lead to oversight when constructing complex SQL queries manually. Fine. But what does that have to do with the root cause, > I was migrating from soft deleting seat claim’s to a new collection explicitly meant for storing the deleted rows. [... I] removed the Paranoia library on the model that had abstracted away the soft deletion logic [...] Reading to the end, I think I've figured it out: > If you don't want to manually archive data all over your codebase, you can build an audit trail at the database layer. > For PostgreSQL, there are a few different strategies to implement this described in our Ultimate Guide to PostgreSQL Data Change Tracking. This can also be automated by services like bemi.io, which plugs into a database and provides immutable records of data changes automatically. I don't hate submarines but I don't like this one.