I see your point, but I think of an optional, disabled by default, feature: the documentation may stress that enabling it would have a massive performance impact, especially on large datasets, with the additional caveat that the choice to enable it is a one way trip, because of the data integrity corruption caused by deletions.

It's one thing to stress that enabling a feature can lead to performance issues but its completely another when the introduction of a feature leads to exceptions in other parts of the code. The code needs to be failure tolerant where applicable and should induce failures where appropriate to prevent further problems. Your mileage my vary here.

A lighter solution may be to provide a mechanism to delete only the column contents except from the structural columns (IDs and FKs), in order to allow the removing of sensitive data and maintain the structural integrity of the audit tables: a support column may be added to each audit table with some info about the deletion (e.g. the c.s.list of the indexes of the erase columns).

This certainly sounds more appealing than just out-right removing rows, but I need to consider a number of factors. I'll leave this open and I'll think on it.