Soft delete: ¿columna deleted_at o borrar de verdad?

Elías L.

Nivel 3 · 28 mar 2026

En mi equipo todo se 'borra' con deleted_at y ya tenemos tablas donde el 70% de las filas están borradas. Todas las consultas tienen que acordarse de filtrar. ¿Cómo lo manejan ustedes?

Respuestas 5

Benjamín F.
Nivel 3 · 28 mar 2026
0 0
El soft delete tiene sentido cuando necesitás recuperar o auditar. Pero aplicado a todo por defecto termina siendo lo que describís: basura que hay que filtrar siempre.
Gastón L.
Nivel 3 · 29 mar 2026
1 0
Alternativa: borrar de verdad y guardar una copia en una tabla de historial o auditoría, con un trigger o desde la app. La tabla principal queda limpia.
Benjamín F.
Nivel 3 · 29 mar 2026
1 0
Si mantienen el soft delete, en Postgres un índice parcial (WHERE deleted_at IS NULL) y una vista con las filas activas ayudan mucho.
Fabricio V.
Nivel 3 · 29 mar 2026
0 0
Ojo con las restricciones UNIQUE: si un usuario se 'borra' y otro quiere registrarse con el mismo email, el soft delete se lo bloquea. Hay que pensar un índice único parcial.
Jhonatan G.
Nivel 3 · 29 mar 2026
0 0
Y con temas de privacidad: si alguien pide que borren sus datos, poner una fecha en deleted_at no es borrar.