Crashing with Scrivener is a lot less scary than single-document programs that lack auto-save.
If you’ve imported hundreds of old documents and done a little organising with index card text, you may already have close to a thousand literal files on the disk. A project that has been heavily outlined and annotated can have tens of thousands, as each entry in the outliner can be represented by up to six different files, and an indefinite number of associated snapshot files (where the text is saved separately and in an immutable fashion for older revisions).
Given how many files can be in a project, Scrivener does not open all of this when you load the project. In most cases it may only load around a dozen files, and most of those will be settings, the file that describes your binder, a search index and maybe some content for the main editor to show. Content files are only loaded when you click on them, and they are periodically flushed from memory if they haven’t been saved or looked at in a while. There are exceptions, but the take-away is that it only loads what is necessary to show what is in front of you in the window.
What this means in practical terms is that your average editing session is likely only going to touch a tiny fraction of total number of files in the project, and of that total that hasn’t saved yet at the moment of the crash, an even more tiny fraction of that fraction. Often a crash or sudden quit results in the loss of a few words that you were typing seconds before.
So we’ve narrowed down what could in theory be corrupted during a crash, from thousands to maybe one or two files, but what about those files? There you’re pretty safe as well because by default Scrivener auto-saves after two idle seconds, which is probably more often than you might think. Just stopping to think about how often that might happen probably took longer than two seconds, and now your stuff is now saved.
That leaves the truly rare event of when the crash or power outage happens in the moment (and we’re talking microseconds here) a file is being saved. And there, thanks to modern file systems there are things happening beneath the software level that help prevent file corruption in such cases.
Real live bona fide data corruption is exceedingly rare thanks to all of the above. You may hear otherwise, but that is because a lot of people use the word ‘corruption’ as a blanket statement to describe any situation where something doesn’t restart the way they left it, essentially (and a good 99.9% of situations like that involve poor use or configuration of cloud sync technology—i.e. nothing to do with Scrivener, but you know how everyone treats the messenger).
On the broader and more preferential matter of how to organise your work, my main answer to that would be: don’t worry about it.
It is a trivial matter to split a project up into several, if it comes to the point where you don’t like working that way. It’s also very easy to combine multiple projects together if you tire of having to switch between them constantly and are finding they could benefit from sharing a lot of text.
You can’t really make many mistakes here, in other words.
I would even categorise performance as preferential. We’re talking a gradual increase in the duration of some operations, and whether that is okay or not okay is a matter of personal tolerance. There are even settings in Scrivener to avoid the worst of these as well. Archive-style projects like this, that rarely change once settled in, can certainly have their backup-on-close default behaviour shut off. Let your normal external backup systems handle them. While creating a redundant copy of the entire project whenever you close it is great for a manuscript you’re in the middle of writing, it’s wasteful and unnecessary for something that rarely changes.
What I would consider of much more immediate impact, than stability or performance, is whether or not it makes sense for all of your writings to share the same pool of metadata. For something like this, an historic archive that is essentially a level up of File Explorer—it’s probably fine.
This is kind of thinking of the future, rather than what you are doing now: once you start getting into using Scrivener to write, from the ground up, and you use those keywords and labels, and start making your own custom metadata fields to track important dates and whatnot—that kind of stuff will tend toward being very integral and unique to each project. So merging such a finished writing project into an archive shared by hundreds of others would either mean an ever growing inscrutable mess of keywords and such, or it would mean losing that kind of information going forward.
In summary: it’s hard to make mistakes, data corruption has no more an elevated risk factor with a million words than ten words, and the software can take many long books without performance drops. All together that means: do what you want.
Perhaps there is a forest for the trees thing going on here.