What would need to be done is to re-design the database so that not all of it needs to be stored by everyone.  Say 3-4 pieces that are redundant, different overlaps between witnesses, etc.  But this is challenging, coding-wise, not to mention an issue once scaled beyond that.

I don't disagree that this is a problem, and I think that there may be a solution.  But we need to figure out how to approach it.

Requiring everyone to have 32 TB of RAM (TB not GB) is far from a solution.

What could be done is a type of 'rolling database' on what is to be paid out that day, but it would require some additional tweaks to the protocol.

Say that you do monthly payouts for all posts.  After the first payout, you fix the 'payout time'.  Then, all you have to do is a pre-fetch of the info stored on the harddrive to RAM so that it can be properly processed at the right time.  Say, you do a pre-fetch 5 minutes before.  After the monthly payout happens, the current queue slowly drains and refills itself, as it drains, it rewrites the fixed monthly payout queue and adds any new posts into this setup.

In this scenario, you wouldn't be storing everything in memory all at once, and you'd probably have negligible amount of posts that are in the same 5 minute window, given that it is a 5 minute window for one month.

You may hit peaks, depending on user activity, but I think the amount in memory would still be low.