Eagle is responsive with a small reference collection, maybe five thousand images. That same app with fifty thousand images becomes noticeably slower at every task. Scrolling through the grid takes longer. Adding a tag to multiple files makes the app unresponsive for seconds. Filtering by a criteria you have applied a hundred times before takes a visible pause. The problem is not misconfiguration and it is not the Mac. It is architectural: Eagle's database grows with every file, and a large database is slower to search through, render and modify than a small one.
The cause: linear growth with collection size
Eagle's architecture is straightforward: you import all your images into a central database, and everything you see — the grid, the filters, the tag suggestions — comes from reading that database. When the database is small, that is fast. At five thousand files, selecting a tag filter and rendering the grid takes milliseconds. At fifty thousand files, the same operation means searching through ten times as much data, and you feel it.
This is not a flaw specific to Eagle. Any app built on an embedded database that holds the complete collection in one file will experience the same slowdown. The database file grows linearly with library size, and read-through time grows with it too.
Coii Ref approaches the problem from the opposite direction. Instead of making you browse the whole collection and filtering it down, it makes you search first and browse the results. That difference is the entire design, and it is why a Coii Ref library of one hundred thousand images stays responsive.
Symptoms: what slowdown looks like in practice
You may notice one or more of these:
- Scrolling through the main grid becomes visibly slower, with several-second delays between page scrolls.
- Adding tags to multiple files causes the app to hang for five to ten seconds while it updates the database.
- Filtering by criteria — even saved filters you use often — introduces a noticeable pause.
- Thumbnails appear slowly, and the app seems to be re-reading the files repeatedly.
- Searching or navigating to a specific file becomes sluggish.
- The app becomes unresponsive when you try to perform multiple operations in quick succession.
None of these are signs of a broken library or corrupted data. They are symptomatic of the database getting large enough that the I/O overhead is no longer invisible.
Why hardware upgrades do not solve this
You might expect that a faster Mac, more RAM, or an SSD would eliminate the slowdown. It does help — a Mac with more RAM will cache more of the database in memory, and an SSD is faster than a spinning drive. But the underlying problem remains: the database is large, and reading a large database takes time. At some point, you are asking the app to do something it was not designed for, and no amount of hardware makes it arbitrarily fast.
A thought experiment: every file you add to an Eagle library makes the collective browsing experience slightly slower, permanently. By design, there is no cutoff where the slowdown stops accumulating. A five-thousand-image library is twice as fast to browse as a ten-thousand-image library, which is twice as fast as a twenty-thousand-image library. The rate of slowdown is predictable and permanent.
Workarounds within Eagle
If you are committed to staying in Eagle, you have two partial solutions:
Create separate libraries by project. Instead of one fifty-thousand-image library, maintain five ten-thousand-image libraries, each optimised for a project or team. The upside is that each one stays fast. The downside is that you cannot search across all projects at once, and you have to manually partition your collection.
Keep the main library on the fastest available drive. Eagle's performance depends partly on how fast it can read and write the library database. An external SSD is faster than an external hard drive, and an internal SSD is faster than either. If your library lives on a slow drive, moving it to a faster one helps. But this is a ceiling, not a solve — at fifty thousand files on the fastest drive you own, you still feel the slowdown.
Neither of these changes the fundamental constraint.
How Coii Ref avoids the problem
Coii Ref's database also grows with collection size, but responsiveness does not. The difference is that Coii Ref never asks you to view the entire collection at once.
Every view starts with a search. Even an empty query — just opening the app — is a
search that returns all files, but that view is never displayed as a scrolling
list of fifty thousand. Instead, you are presented with the first couple hundred
in a grid, and navigating means narrowing the search. rating:>=3 cuts it to a
few thousand. type:video cuts it to hundreds. The app is always showing you a
result set that is smaller than the whole collection, and rendering a smaller set
is fast.
This is a design constraint: you cannot simply browse a Coii Ref library by scrolling, the way you can an Eagle library. But the constraint buys you something: no matter how large the collection grows, the view you see stays fast because it is only showing you what you asked for.
Saved views make this concrete. rating:>=4 tag:studio -is:favourite is a single
line you can type once and save. Every time you open it, Coii Ref re-parses the
query and returns only the results — a few hundred, in this case. The fact that
there are fifty thousand images underneath does not make the saved view any
slower.
The importer can carry ratings, tags and notes from Eagle to Coii Ref by matching relative paths. If you have spent years building a tagged Eagle library and you want to move it, you do not start over.
The underlying trade
There is a real trade between Eagle's design and Coii Ref's. Eagle lets you browse: open the app, see everything at a glance, apply a filter, narrow the view. That browsing experience is fast at small scales and slows down predictably as the collection grows. This is not a limitation unique to Eagle; any app that loads the entire collection into a visual browse interface will experience the same slowdown as the database grows.
Coii Ref forces you to search: you cannot browse a fifty-thousand-image library
by hand, so instead you learn to construct queries that answer the questions you
actually ask. type:video tag:motion is how you find videos tagged motion. After
a few days of using the query language, most users find it faster than clicking
through filters, and it remains fast no matter how large the library grows.
This is not because Coii Ref has a faster computer underneath; it is because the
app fundamentally works differently.
The trade is real: if you have five hundred images and you want to see everything at once, Eagle is better. If you have fifty thousand images and you never want to scroll, Coii Ref is better. For most working reference libraries, the second case describes the scale and the workflow after the first year or two.
When performance matters most
Performance degradation becomes a daily frustration at specific scales. A fifteen-thousand-image library in Eagle may still feel responsive, but twenty thousand starts to show lag. By thirty thousand, every operation has a noticeable delay. At fifty thousand and beyond, the app is slow enough that you start asking whether there is a better tool.
If you are building a library from scratch and you are uncertain about scale, trial Coii Ref for a fortnight with your existing images. The difference in responsiveness becomes clear at large scales: one app stays fast, the other does not. The choice is simpler when you have experienced both at the scale you actually work at, not just in theory.
Additionally, some of Eagle's slowdown is not inherent to the app but to how your specific collection is structured. Large numbers of very high-resolution images, for instance, make database operations slower than an equivalent number of smaller images. Video files make the database larger. But even accounting for these factors, the fundamental architecture means that a fifty-thousand-file library will always be slower in Eagle than in Coii Ref at the same search operation.
A note on database optimization
Some users find that periodically optimising Eagle's database helps — compacting the database file, removing duplicates, consolidating the library. These steps help temporarily but do not address the root cause. The slowdown returns as the library grows again because the problem is structural, not cosmetic. A database that holds fifty thousand records is inherently slower to query than one holding five thousand, and no optimisation changes that fact.
If you have been running Eagle for years and you have optimised the database multiple times, looking for a different tool is rational rather than a failure on your part. You have simply outgrown what the architecture can comfortably deliver.
Migration path
Moving a large Eagle library to Coii Ref is straightforward and reversible. You keep the originals, run the importer to bring ratings and tags across, and run both apps in parallel for a week while you get used to the new query language. Coii Ref's one-line search is unfamiliar at first, but it becomes faster than clicking through filters once you understand the syntax.
If you decide to go back, your files and your Eagle library are still intact. If you stay, you free up roughly half the disk space (because Coii Ref indexes instead of copying) and you regain responsiveness at scale.
Also worth reading: the other common Eagle issue is how storage grows, and how to organize video references if video is part of your collection. The best reference apps that don't copy files guide covers the index-based alternatives.
When to make the switch
If you are at the point where scrolling through your Eagle library feels like punishment, the answer is clear: try something else. The trial is free and the worst that happens is you spend an evening discovering that the problem is real and the solution works.
A lot of time gets spent trying to work around performance limits instead of accepting them and moving on. If you find yourself closing other applications to make Eagle faster, or scheduling work for times when the library might be responsive, that is the signal. You have hit a wall the app is not designed to pass. How to keep a reference library tidy without refiling suggests maintenance strategies that help with large libraries.
The comparison covers what else differs between them and how the indexing approach changes the workflow. Or just download the trial — thirty days, every feature, no card, and the price does not come up until after.