I appreciate your thoughts here on pre-mature optimization. 
The use case is not “a few thousand rows” (unless you mean the per-second use-case); it is billions of rows. The database, in this case, PostgreSQL, may actually be cool with the insert performance required but there’s also the storage cost to consider: With the ValidityAuditStrategy you have at least 2x the number of “actual” rows regardless if there are row changes or not. So it becomes 2x X billion rows. That would be a waste.
In conclusion, it would be natural if this particular table used DefaultAuditStrategy, while the others could continue to use ValidityAuditStrategy. This is not currently possible with Envers. Don’t know if supporting multiple “realms” (Envers configs) within the same EntityManager would be a major undertaking or not for Envers. , or if such use case is isolated to me.
I could maybe have 2 different DataSources to facilitate two different Envers configs (e.g. two different classes annotated with @RevisionEntity), but I wouldn’t know how to actually do it.