[kthejoker2]

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.

[darkwater]

Well, compliance (as in GDPR) might actually force you to not soft-delete in some cases.

[EdwardDiego]

Yeah, 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]

IMO 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]

Good point there.