4 ms·
The main problem I have is the article takes a performance/devlopment lens to soft deletes, and only pays lip service to the objectives you're trading off perfo
by kthejoker2 2y ago
The main problem I have is the article takes a performance/devlopment lens to soft deletes, and only pays lip service to the objectives you're trading off performance for with soft deletes ... namely data retention / disaster recovery / audit requirements.
* availability / recovery - soft deletes provide the best RPO/RTO in archival / lifecycle planning
* auditability / compliance - much easier to achieve with 1 system than 2 or 3 systems
* security - see above
You certainly can achieve these objectives with CDC / snapshotting / warehousing / archival practices, but the soft delete pattern has its place at the application layer in spite of performance which is only begrudgingly acknowledged in the article.
- EdwardDiego 2y agoYeah, before breaking out Debezium, Kafka Connect and S3, consider soft delete first. It might not scale, but maybe you don't need to scale just yet, and maybe a column called is_deleted is far more appropriate and far less complex for your current purposes.
- oxidant 2y agoIMO deleted_at, either with null or epoch as the "not deleted" value is nicer than is_deleted because it allows some level of auditing.
- EdwardDiego 2y agoGood point there.
- darkwater 2y agoWell, compliance (as in GDPR) might actually force you to not soft-delete in some cases.