Soft delete strategies, like using a deleted boolean or an archived_at timestamp, are common in software projects to help recover accidentally deleted data. While they simplify customer support and compliance, they introduce complexities. For instance, maintaining an archived_at column can lead to numerous dead rows in the database, as most archived records are seldom accessed. Over time, this dead data can accumulate, complicating database management and slowing down backups, especially if the project lacks a cleanup routine. Queries become more complicated with soft deletes. Developers must ensure they filter out archived data from live data, which can result in bugs or performance issues. The article critiques the simplicity of soft delete approaches, suggesting that they might seem straightforward initially but lead to significant pitfalls later on. The author shares experiences with migrations that involve archived data and the challenges that arise when restoring records, which can require more than just a simple database operation. Alternatives to traditional soft deletes are discussed, including application-level archiving, triggers, and change data capture (CDC). The application-level approach involves sending delete events to a message queue, allowing another service to archive the data externally, such as in S3. While this method simplifies the primary database, it introduces more potential for bugs in the application code and requires additional infrastructure. Triggers can automate the archiving process and avoid cluttering live tables with archived data. This method keeps live tables clean, makes queries more efficient, and simplifies application logic. Finally, using CDC tools like Debezium allows for real-time archiving by capturing changes from PostgreSQL’s write-ahead log, offering a scalable solution for managing deleted records.