We ran into a very similar situation during one of our migrations, and honestly, what you're seeing with pelog is pretty normal at that scale. Once you get into billions of rows, it just crawls.
From experience, neither pelog nor the Audit Disposition Policy is going to be “fast” here. They’re both safe and supported, but they’re not built for heavy bulk cleanup like this. So if you stick with them, it’s going to take a long time.
Your first idea, deleting directly at the database level using a date filter, is actually what most teams end up doing in cases like this. It’s significantly faster. The only thing is you need to be careful and controlled with it. Don’t try to wipe everything in one go. Do it in chunks, maybe by date ranges, and keep an eye on locks and transaction logs.
What has worked well for us is a mix of both approaches:
Do the heavy cleanup directly in the database in batches
Then run pelog afterward just to let FileNet clean up anything it still needs to handle internally
Also, if those tables are heavily indexed, the deletes can slow down a lot. In some cases, temporarily adjusting indexes (or at least being aware of them) helps, then rebuilding afterward.
If your compliance rules allow it, another angle is simply not carrying all that historical log data into the new environment. Sometimes that’s the biggest time saver.