Soft delete is a database pattern that marks a record as deleted instead of permanently removing it from storage. Applications typically hide marked records from normal views while allowing authorized users or automated jobs to restore or permanently purge them. It is useful when recovery and history matter, but it requires consistent query filtering and a clear retention policy.
Soft Delete
What Is a Soft Delete?
Soft delete marks a database record as deleted without permanently removing it. Applications hide the record from normal views, but authorized users can restore it or purge it later. Databases commonly use a deleted_at timestamp or is_deleted flag.
How Soft Deletes Work in a Database
A soft delete updates a record instead of physically deleting it. The application must apply the deletion marker consistently in screens, APIs, reports, and search results.
- A user deletes a record, such as a project or customer profile.
- The application sets a marker, such as
deleted_at. - Normal queries exclude marked rows.
- An authorized user can restore the record by clearing the marker.
- A purge job permanently removes records after the retention period.
Soft Delete vs. Hard Delete
Hard delete removes stored data. The right choice depends on recovery needs, storage rules, and privacy obligations.
| Consideration | Soft delete | Hard delete |
|---|---|---|
| Data action | Marks the record as inactive or deleted. | Removes the record from storage. |
| Recovery | Usually possible before a purge. | Requires a backup, if one exists. |
| Storage impact | Table and index size can continue to grow. | Frees active storage space. |
| Relationships | Can preserve related records and references. | May require cascade or orphan handling. |
| Privacy requests | May be insufficient when data must be erased. | Often needed after a valid retention period. |
A SQL DELETE command without a WHERE clause can remove every row in a table. It is a hard delete, not a soft delete.
Benefits of Soft Delete
Soft delete is useful when deletion should be reversible for a limited time.
- It lets users or support staff recover records deleted by mistake.
- It preserves context for support investigations.
- It supports archive-like behavior without breaking related records.
- It provides a controlled restore workflow.
Practical Limits of Soft Delete
Soft delete is not a substitute for a backup, audit log, or retention policy.
- A missed query filter can expose hidden records.
- Deleted rows can increase table, index, cache, and search complexity.
- Existing unique values, such as an email address, can block replacement records.
- Sensitive data may require permanent erasure.
- A deletion timestamp does not explain every record change.
Safe Implementation Practices
A reliable design makes deletion behavior automatic and testable.
- Use a
deleted_attimestamp and, where useful, record who deleted it. - Centralize default query scopes that exclude deleted records.
- Limit restore and purge actions with role-based permissions.
- Use partial unique indexes where supported.
- Test lists, APIs, search, and exports.
- Document retention periods and monitor purge jobs.
Soft Delete in Applications Built With Emergent
When building a full-stack application with Emergent, teams can specify reversible deletion, restore screens, role permissions, filtered views, and scheduled purges as requirements. These workflows are part of sound software development, especially for applications created with an AI app builder that need safe data management from the start.
Start Building
on Emergent today
on Emergent today
Start Building
