Soft delete en PostgreSQL: desafíos y alternativas prácticas

¿Qué es el soft delete y por qué se utiliza?

El soft delete es una técnica utilizada en bases de datos para marcar registros como eliminados en vez de borrarlos físicamente. En aplicaciones SaaS y productos data-driven, especialmente los basados en PostgreSQL, esta práctica permite preservar histórico para auditoría, recuperación y sincronización. Habitualmente, esto se implementa agregando una columna (ej. archived_at o deleted_at) que indica cuándo se marcó un registro como eliminado.

Desafíos técnicos y de diseño del soft delete

Si bien el soft delete facilita la reversión y auditoría, también puede aumentar la complejidad de las consultas (hay que filtrar explícitamente datos eliminados), incrementar el volumen de datos inactivos y originar problemas en migraciones, restauraciones y la lógica de la aplicación. Este enfoque puede ralentizar consultas críticas de negocio y confundir integraciones externas si no se implementa correctamente.

Alternativas al soft delete tradicional

1. Archivado por eventos a nivel de aplicación

En sistemas modernos, se puede capturar el evento de eliminación en la lógica de negocio y enviar los datos a una cola de mensajes para archivarlos fuera de la base de datos transaccional. Esto habilita flujos asíncronos y escalables, pero implica mayor complejidad operativa e integración con sistemas como Kafka o servicios de mensajería.

2. Triggers de base de datos para mover datos a tablas de archivo

Configurar triggers en PostgreSQL permite mover registros eliminados a una tabla secundaria de archivo, manteniendo la base principal limpia y mejorando el rendimiento en las consultas. Es considerado el enfoque más simple y robusto para proyectos nuevos.

3. Captura de Datos de Cambio (CDC) vía WAL

El uso del Write-Ahead Log (WAL) de PostgreSQL y herramientas como Debezium permiten detectar y capturar eliminaciones para procesarlas externamente o sincronizar sistemas. Este método es ideal para arquitecturas orientadas a eventos o cuando se necesita construir históricos detallados o data lakes.

4. Réplica de sólo inserciones

Una idea más experimental es configurar una réplica de PostgreSQL que ignore los DELETE, reteniendo así todos los cambios históricos. Es útil para casos de auditoría extrema o regulaciones de compliance, aunque su viabilidad depende del volumen de datos y mantenimiento requerido.

Buenas prácticas y recomendaciones

• Elige el enfoque según la criticidad de los datos y el volumen esperado.
• Documenta claramente la lógica de borrado y diseñe APIs coherentes.
• Evalúa los triggers para proyectos nuevos; para arquitecturas distribuidas, considera CDC.
• Realiza mantenimiento regular de datos inactivos para evitar degradación de performance.

Conclusión

El manejo de soft delete impacta directamente en el rendimiento y mantenibilidad del producto. Seleccionar la estrategia correcta desde el inicio, en especial basada en triggers para nuevos proyectos, reducirá fricciones técnicas y facilitará escalabilidad. Evalúa las alternativas según el contexto de negocio y apuesta por claridad operativa.

Fuentes

1. https://atlas9.dev/blog/soft-delete.html (fuente original)
2. https://martinfowler.com/articles/soft-delete.html (fuente adicional)
3. https://www.prisma.io/dataguide/postgresql/data-modeling/soft-deletes-in-relational-databases (fuente adicional)
4. https://debezium.io/documentation/reference/stable/ (fuente adicional)

Artículos relacionados:

Locks en PostgreSQL: tipos y optimización para SaaS Pg_lake: Postgres con acceso a Iceberg y data lake – Cómo funciona Evita UUIDv4 como clave primaria en PostgreSQL SaaS Ser emprendedor: 3 historias reales que te harán explotar la mente Miembros