Many reference managers work fine until you test them at scale. A small library of a few hundred images opens quickly, search is responsive, and the app feels snappy. Index five thousand images and the app slows noticeably. Index ten thousand and it hangs. Index twenty thousand and it crashes.
This is not a bug in the sense of something going wrong. It is a design problem: the app was built assuming a certain library size and did not account for what happens when that assumption breaks.
The cause: bulk loading and memory pressure
Most reference managers use one of two architectures, and both hit a wall at large scales.
The first loads all file metadata into memory when you open the app or a folder. This is fast for small folders because memory access is quick. But for a ten-thousand-image folder, loading ten thousand files' worth of EXIF, dimensions, color profiles, and thumbnails into memory exceeds what most apps allocate. The app runs out of memory and crashes.
The second uses a database—SQLite, PostgreSQL, or a proprietary store—but queries it inefficiently. Instead of fetching only the metadata the UI needs to display, it fetches everything. For a large library, this means reading the entire database on every operation, which is slow and resource-intensive.
A third pattern, common in older apps, is to generate all thumbnails upfront and cache them. A ten-thousand-image folder means ten thousand thumbnails cached to disk, which can consume gigabytes and make the app sluggish when the cache is referenced.
All three approaches break at the point where the library becomes large enough that processing everything at once is not feasible.
When crashes start to appear
The crash threshold depends on the app and your Mac. A newer Mac with 16 GB of memory can often push an inefficient app further than an older Mac with 8 GB. But even a well-specced Mac has a limit.
- Five thousand images: A poorly designed app crashes here. Memory use spikes, the database times out, or file handle limits are exceeded.
- Ten thousand images: Most apps that are not designed for scale show problems. Crashes are frequent, slowdowns are visible, and the app becomes unreliable.
- Twenty thousand images: Even well-designed apps can struggle if the architecture assumes a smaller library.
If your library is growing and the app is crashing more often, the crashes are not random. They are a signal that you have exceeded what the app was built to handle.
The symptoms to watch for
Before a crash, you usually see warning signs:
- Opening a large folder takes several minutes instead of seconds.
- Scrolling through results is jerky or stalls completely.
- Searching takes ten seconds or more for simple queries.
- The app becomes unresponsive when importing a batch of files.
- Restarting the app temporarily fixes the problem, suggesting memory is accumulating.
If you see these symptoms, the app is hitting its limits. A crash is usually the next step.
Why your Mac's memory is not the answer
It is tempting to think that a Mac with more memory would solve the problem. Sometimes it does, but only temporarily. If the app's architecture is inefficient, giving it more memory just moves the crash point higher, not eliminates it.
An app that loads all metadata into memory at startup is fundamentally limited by how much metadata it can fit. More RAM helps, but only if you never exceed the app's maximum memory allocation. Once you do, the app crashes, and you need even more RAM. This is not a scalable solution.
The real solution is a different architecture: lazy loading, efficient queries, and on-demand rendering. These allow the app to handle large libraries without needing gigabytes of memory or minutes of startup time.
~/Pictures/References- Archive
- Current
- Inspiration
- coii-thumbnailswritten by Coii Ref
- coii-proxieswritten by Coii Ref
- coii.dbwritten by Coii Ref
Why large libraries crash other apps specifically
Reference managers are more vulnerable to scale problems than other tools because they do two things simultaneously: index files and generate thumbnails. Indexing requires reading file metadata (dimensions, EXIF, color), and thumbnails require either generating them upfront or storing cached versions.
A photo library app that only stores photos you explicitly import has fewer files to manage. A file browser that does not generate thumbnails is faster at opening large folders. A reference manager does both, which is why the crash point is lower.
The problem is worse if the app also imports from other tools (matching metadata, merging libraries) or stores its data in a complex format that requires parsing on startup.
What to do if your app crashes on your library size
If your reference app crashes regularly:
Confirm it is the library size. If crashes happen as soon as you index a large folder, and they do not happen with a smaller folder, library size is the cause.
Check whether splitting the library helps. If splitting a ten-thousand-image folder into two five-thousand-image folders both load without crashing, you have confirmed the ceiling. But this is a permanent workaround that makes searching and organization harder, not a solution.
Try switching to a different app designed for large libraries. If the crashes are frequent and splitting does not help, the problem is architectural. An app designed to handle twenty thousand images without memory pressure will be noticeably more responsive and reliable than one crashing at ten thousand.
Test at your actual scale before committing. If you are comparing apps and you have a ten-thousand-image library, index that library in each app before deciding. A trial that tested on a small library will not show you the crashes you will experience at scale.
Why Coii Ref does not crash on large libraries
Coii Ref indexes files without loading all metadata into memory. It reads file info on-demand, uses a database designed for efficient querying, and generates thumbnails as you scroll rather than upfront. A ten-thousand-image folder opens in seconds and stays responsive no matter how large the library grows.
The architecture is designed for scale from the start. The database can handle hundreds of thousands of files, and the search is fast at any size because it only processes the results that match, not the entire library.
This is not a performance optimization added later; it is how the app is fundamentally built. The cost is that you cannot casually browse the entire library the way you can in an app that loads everything into memory. The benefit is that your app does not crash as the library grows, and you do not spend your time managing the tool instead of using it.
For a working library that is growing or that reaches a certain size every year, this difference becomes the main reason to switch. An app that crashes at five thousand images but runs stably at fifty thousand is not just faster; it is actually usable at the scale your workflow requires. The transition from a crashing app to a stable one is transformative—suddenly your library becomes something you work with instead of something that constrains your work.
Check how to index a 40,000-image folder for steps on large libraries, and read how to keep a reference library tidy without refiling for maintenance at scale. If comparing apps, the best reference apps that don't copy your files covers the landscape, and does Eagle copy your files for one competitor's approach to the problem. How to build a reference library from existing folders walks through the complete migration process if you are moving from a crashing app. The 30-day trial comes with every feature and no card.
When slowness becomes the deciding factor
An app that slows down at five thousand images but crashes at ten thousand is fundamentally broken for anyone working at scale. The crashes are not glitches—they are signals that the design cannot support your library. Switching is not about having a faster machine or more RAM. It is about using an app built to handle the size your collection has grown to.
If you have ten thousand images today and your collection is growing, you will have twenty thousand in a few years. An app that crashes at ten thousand will still crash at twenty thousand, and no amount of optimization will change that. The math does not work. The only fix is an app with a better architecture.
Most importantly, do not wait until the crashes become severe. Test your reference app with the actual library you have now. Do not wait for the app to fail in production when you are on deadline, trying to find an image, and the application exits instead. Test it now, when you still have time to switch if needed. The thirty-day trial is designed exactly for this—to let you experience what stability at your scale feels like in an app designed for it.
Most users who try Coii Ref with their actual ten-thousand-image collection find the difference in speed and responsiveness immediately obvious. They are not waiting for the app to crash; they are experiencing what it feels like to work with a tool designed from the start to handle libraries that grow. Opening a folder is fast. Searching returns instantly. Scrolling is smooth. No spinning wheels, no progress bars, no moments of unresponsiveness while the app struggles to keep up. This is what a properly designed application at scale feels like, and it is exactly what your workflow deserves when your libraries actually matter.
A simple test before you commit to a new app
Before switching from a crashing app:
Test at your actual scale. If you have ten thousand images and are evaluating a new app, do not test on a small sample. Index your entire library in a trial. Watch for the signs—slowdowns, unresponsiveness, crashes—at the scale that matters. A trial that performs well on a thousand images might fail at ten thousand, and you will only know if you test the real thing.
Let it run for a few days. Do not just open the folder once and declare it stable. Use the app as you would for real work. Search, open images, modify metadata, create views. The crashes often appear under real-world usage, not just on import.
Compare memory usage between apps. Open the same folder in two different apps and watch the Activity Monitor. If one app uses gigabytes of memory while another uses hundreds of megabytes, that is a signal about architecture. The one using less is probably designed for scale.
If an app handles your ten-thousand-image library smoothly, it will handle growth and reorganization without the crashes. If it crashes at your current scale, it will keep crashing as the library grows, and no amount of RAM will fix the underlying problem.