post_history is the big one, but moderators and (IMO) affected users need to be able to access user history too (name changes, bio changes, gravatar changes, etc), and vote history probably needs to be in the main DB too for rep-tracking and (in)validation.
I don’t know if all history substantially exceeds that, and sorry I didn’t realize that’s what you were talking about. I don’t know if all history needs to be in the main DB, but some of it does.
In general, the history tables will take care of Post History too - the functionality is really the same. However, one exception that we haven’t addressed yet is “Pending Edits”. They don’t go to the main Post (and copy to Post History) because they haven’t been Approved yet. Plus each Edit will need tracking of the Approvals. On the other hand, these Pending Edits will only affect Title (for Q), Body Text and Tags, so the table needed for them is relatively small. Once an Edit is Approved, the Post gets updated, Post History automatically added and Post Edit cleared out (but the details archived in Post Edit History, etc.).
I agree with the storage cause its not that expensive indeed.
Also I saw the audit/history approach on some older database, it isn’t so bad. Its even very handy sometimes. It can also take care of the post history as you said.
The only thing is with the reviews of posts/edits I feel like we are swimming out of MVP zone and into a more fleshed out project.
Edit reviews will be needed, particularly as the site gets rolled out to the general public. Less of an issue if most users are experienced users migrated from SE. We can include the database structure needed even if we don’t implement the actual Edit Queue/Approval process MVP.