Wow, what a blast from the past Here’s what I can say 3 years later…
“It all depends”
From a technical perspective, however many rows the database can store is the limit. So, 2 billion? I have no idea if MySQL has a limit.
But then you get into how optimized the system is for various use cases. We still run into significant slowness (in my own judgment) with 150k records in Omeka-S v1.4.0. However - exactly how much slowness depends on your system specs and any database tuning/performance optimization you might have done or be able to do.
Now with the new v2+ of Omeka-S, I understand from the release notes they’ve made some significant improvements to internal indexing and search optimization - I just haven’t been able to proceed with testing because we are waiting for some of the site modules to be upgraded to be compatible.
But beyond my overall comment of “it all depends”, which is what I’ve learned in the past 3 years of working with Omeka/Omeka-S - the other factor that would be important to note is that Omeka-S (I believe) is designed to have a shareable pool of resources in which any particular sub-site does not display the entire pool. The developers or staff at RRCHNM might comment on that and amend it, but as far as I can see, if you have a single collection with 1 million records, vs. 100 collections each with 1k-10k records, that’s a big difference in terms of how well Omeka-S will function on the front-end.
FWIW, my 2 cents 3 years later
– Ben Bakelaar