Page 1 of 1

Large Library Advice or Options??

Posted: 17 Jun 2025, 22:15
by John9871
Hello,
Question / seeking advice.

I recently split my libraries, because I was noticing libraries over around 4000 items were getting really slow to work with. So I split my libraries into different genres to help - so that the large libraries were still less than 5000 items or so. All totaled, I probably around 15000 items. But if that was all in one library, that library would be REALLY REALLY slow to work with. But now, I'm struggling because I have to maintain multiple sets of tags, and other meta-data across each library (about 5 of them)

I'm guessing that is just part of having a large library, and there really isn't anything I can do, but I figured I'd at least ask. Is there anything else I could do to have all the items be in one library but without being so slow?

Thanks very much,
-john

Re: Large Library Advice or Options??

Posted: 27 Jun 2025, 12:12
by admin
Hello,

Sorry for late replay, I overlooked your post somehow.

Could you please provide more details - what exactly is slow in your case?

Re: Large Library Advice or Options??

Posted: 25 Jul 2025, 21:07
by John9871
No problem on the delay... thanks for the followup.

So I have a few DB's. Here's the stats on what I was referring to. I'd love to combine DB's, but I fear that the larger DB's are already so much slower than the small ones, that one single large DB would be extremely slow.

Load Times (i.e., loading a library)
DB of 1000 items: 4.5 seconds to load
DB of 3000 items: 12 seconds to load
DB of 6000 items: 14 seconds to load


Updating a view (i.e., applying a filter, from time hitting apply to list being updated)
DB of 1000 items: 2 seconds to refresh
DB of 3000 items: 4 seconds to refresh
DB of 6000 items: 10.5 seconds to refresh

So as you can see, my worry is that if I had a DB of say 12,000 items, it would take (in theory) 30 seconds to load, and 20 seconds to refresh every time. It's not terrible, but I was just wondering if that's just a byproduct of large DB's, and I'm better off keeping the DB's smaller, broken into smaller chunks, as opposed to all in one big DB.

Thanks for the insight!