deletedAt

DeletedAt refers to a timestamp column used to implement soft deletion in databases and application layers. The column, commonly named deleted_at, indicates whether a record has been logically removed without being physically deleted. A null value typically means the record is active, while a non-null timestamp marks it as deleted and retained for potential recovery or auditing.

Implementation and usage

The deleted_at column is usually nullable and indexed to support fast filtering. Applications configure queries to exclude rows where deleted_at is not null, while offering options to include or restore soft-deleted records. This approach preserves data for recovery, historical analysis, and audit trails, and it often requires additional logic to handle related data and integrity.

Framework and ecosystem patterns

Soft deletion is widely supported by ORMs and frameworks. For example, Laravel’s Eloquent uses a SoftDeletes feature based on deleted_at, providing methods to restore and to query trashed records. Other ecosystems implement similar behavior via plugins, scopes, or custom conventions. While the exact mechanics vary, the core idea remains the same: separate the notion of a record’s logical deletion from physical removal.

Considerations and trade-offs

Soft deletion can complicate referential integrity, constraints, and data retention policies. It may lead to data growth and require periodic purging policies. Time zone handling for the timestamp matters for accurate auditing. Regulatory requirements such as GDPR may influence retention strategies and data restoration options.

Restoration and hard deletion

Restoring a record typically involves setting deleted_at back to null. A hard delete permanently removes the row, which can be scheduled or triggered after a retention window. Queries focusing on active data generally filter on deleted_at IS NULL.