Why finding a clip on a NAS is slow, and what an index actually fixes

Spotlight on your own Mac is uncanny. You type four letters and the answer is already there, before your hand leaves the keyboard, out of a couple of million files. Then you point the same search at the NAS holding your footage and it becomes a progress bar, then a spinner, then a decision about whether this is worth waiting for.

Same Mac. Same keystrokes. Wildly different experience. The reason is not that the network is slow. It is that on your local disk, somebody wrote the answer down in advance, and on the share, nobody did.

This piece is about that: what an index is, why network shares mostly do not have one where you need it, what the vendors provide instead, what changes when the index moves onto your own machine, and the three real costs of having one. Along with the part most articles skip, which is what a filename index fundamentally cannot answer.

Two different questions both called "search" #

Before anything else, separate two problems that share a word.

Finding a file by its name or path. "Where is A007_C012?" "Show me everything under the client folder shot in March." This is a question about metadata, meaning the names, sizes, dates and locations of files rather than their contents. It is a solved computer-science problem and the solution is an index.

Finding a shot by what is in it. "The wide of the harbour at golden hour." "Every take where she is holding the mug." This is a question about the pixels, and it needs something to have watched the footage and written down what it saw. That is a completely different technology with completely different costs, and we treat it separately in AI search in creative storage, explained and local versus cloud AI indexing.

This article is entirely about the first one. It is the less glamorous half and, for most editors most days, the half that actually eats the hours.

What an index is, in one paragraph #

An index is a database that holds a copy of the metadata, arranged so a question can be answered by looking in one place instead of many. Without an index, "find every file whose name contains C012" means visiting every file and checking. With an index, it means one lookup in a sorted structure, which stays fast as the collection grows: doubling the library does not double the search. Spotlight is an index. Universal Search is an index. The thing that makes your local disk feel psychic is not the disk. It is the index that was built quietly while you were doing something else.

The whole of this article is one question restated: where does that index live, and how far is it from you?

What Finder actually does on a share #

macOS Spotlight indexes local volumes. It does not maintain a Spotlight index of an arbitrary third-party network share, which is Synology's own guidance to Mac users as well: Spotlight on the desktop searches local files.

So when you search a mounted SMB share, one of two things happens.

Either the server can answer. Some servers implement a search service that Finder can query, backed by an index the NAS maintains. When that works, your query is one request across the wire and one answer back, and it is fast, because the expensive part was done in advance on the NAS.

Or nobody has an index, and the search becomes a walk. The client opens the top directory, lists it, then opens each subdirectory, lists that, and recurses. Every one of those steps is a round trip: a question sent and an answer waited for. This is the case that feels broken.

The walk, counted #

Put numbers on it, because the numbers are the argument.

Take a library of roughly 131,000 entries, which is an ordinary size for a facility with a few years of projects on the shelf. Suppose it is arranged in about 4,000 directories, which is also ordinary once you have card folders, dailies, VFX pulls and renders.

A recursive walk has to open and enumerate every one of those 4,000 directories. If each directory costs one round trip to open and one to enumerate, that is 8,000 round trips minimum, and directories with many entries take several enumeration batches, so the real figure is higher. At a LAN latency of 0.3 milliseconds per round trip, 8,000 round trips is about 2.4 seconds of pure waiting, before the client has done anything with the results.

That is the optimistic case. On a busy share, or with per-entry attribute checks layered on, or over a VPN where a round trip costs 20 milliseconds instead of 0.3, the same walk costs 160 seconds. Nearly three minutes to answer "where is that clip." And the answer scales with the size of your library, which is precisely the wrong direction: the more work you have done, the slower it gets to find any of it.

This is the same round-trip arithmetic that makes ordinary browsing feel slow, worked at a much larger scale. We took that apart in why SMB browsing feels slow on a Synology or QNAP, and over a remote link in why your NAS feels slow over a VPN.

The server-side answer: what the NAS vendors give you #

Both major NAS vendors ship a real indexer, and both are genuinely good. Use them before you consider anything else.

Synology Universal Search builds an index of your shared folders on the NAS. Synology's documentation is explicit that fully indexed folders mounted over SMB can then be searched from Finder itself, which is the arrangement you want: the index is built on the NAS, and Finder's search box queries it rather than walking the tree.

QNAP Qsirch does the same job on QTS and goes further into content. It indexes in the background, searches filename, content and metadata, applies OCR to text inside images, and it honours QTS permissions, so a user only finds files they are already authorised to see. That permission behaviour is not a small detail on a shared volume with client material on it.

Both have the same shape of catch, and it is worth naming rather than glossing.

• The index must be built, and rebuilt. Indexing a large media volume for the first time is hours of the NAS working hard. If your library changes constantly, the indexer is constantly working.
• The index lives on the far side of the wire. A query is one round trip instead of eight thousand, which is a vast improvement, but it is still a round trip. Over a VPN with 60 millisecond latency, "instant" becomes "noticeable."
• It depends on the vendor's implementation staying good. You are inheriting whatever the indexer's freshness, its resource limits, and its interaction with your particular DSM or QTS version happen to be.

For a team in one building on a healthy LAN, server-side indexing is often the whole answer, and it costs nothing extra.

What changes when the index is on your Mac #

The other place to put the index is on the client. This is what a caching mount does, and it is the same architectural trick Spotlight uses: keep the answer on the machine asking the question.

JuiceMount keeps the filesystem's metadata in a SQLite database on your Mac's own SSD. SQLite is a small, well-tested embedded database, and putting an index in it is unglamorous and extremely effective. A filename search across roughly 131,000 entries answered in about 29 ms on the author's rig. Directory opens on a volume with more than 100,000 entries measured 15–120 ms, against 3 to 10 seconds through raw FUSE without that layer.

Those figures are the author's own measurements on an Apple-Silicon Mac talking to a TrueNAS SCALE box over 10 GbE, published with the methodology and the harness so you can reproduce them. They are not independent benchmarks and your hardware will differ.

The interesting part of that 29 ms is not that it is a small number. It is what the number is made of: zero network round trips. The query never leaves the Mac. Which means the figure barely changes when you are at home on a VPN, or on hotel wifi, or on a plane, because the thing that usually makes remote search unbearable, latency, is not in the path at all.

In practice that turns search into a different kind of tool. It stops being something you do when you have exhausted your memory of the folder structure, and becomes the way you navigate. In JuiceMount that is a global hotkey from any application, with spacebar for Quick Look, Enter to reveal in Finder, and a result you can drag straight into a Premiere, Resolve or Final Cut timeline.

The three costs of an index #

Nothing here is free, and I would rather list the costs than let you discover them.

Staleness. An index is a copy, and a copy can be wrong. If someone drops 400 files onto the volume from another machine, your index has to learn about them. Every indexed system solves this with some combination of change notifications and periodic rescans, and every one of them has a window where the index and the truth disagree. This is the real cost, it is unavoidable, and any vendor who tells you their index is never stale is describing a wish.

Disk. The index occupies space on whichever machine holds it. For path and filename metadata this is small relative to media, but "small" is not "zero", and on a Mac with 40 GB free everything is expensive.

Build time. The first index of a large library takes as long as it takes to read the metadata for every file in it. That is a one-time cost you pay at setup, and it is the reason the first hour with any indexed system feels worse than the second.

What a filename index cannot do #

Stated plainly, because this is where marketing in this category gets loose.

• It does not know what is in the frame. No amount of path indexing finds "the wide of the harbour." That needs a model that has looked at the pixels, which is a different product with a different bill.
• It does not read inside your project files. "Which timeline used this clip" is a question about a Premiere or Resolve database, not a filesystem.
• It is only as good as your naming. An index over Untitled_final_FINAL_v2_use_this.mov returns exactly what you put in. Camera-generated names are consistent and therefore searchable; hand-typed ones are not.
• It does not make the file open faster. Finding a clip in 29 milliseconds and then waiting for a cold 8 GB file to stream are separate problems with separate answers.

Choosing where the index lives #

The decision is short.

1. If you do not have an index at all, get one. Turn on Synology Universal Search or QNAP Qsirch. This is free, it is supported by the vendor who sold you the box, and for a team on a LAN it may end the conversation.
2. If the index is on the NAS and you work remotely, notice what latency does to it. One round trip is fine at 0.3 milliseconds and irritating at 60. If your search feels fine at the office and bad at home, that gap is the round trip and nothing else.
3. If you want search that behaves the same everywhere, the index has to be on the client. That is the only arrangement where the network's condition stops being a variable in how fast you can find things.
4. If your real question is "what is in the footage," none of this is your answer. Go read the AI-search pieces linked above and price that separately, because it is priced separately.

The honest summary is that this is not a hard problem and it has been solved several times. It is just that the solution has to be somewhere, and the difference between a search that takes 29 milliseconds and one that takes three minutes is entirely a question of how far away that somewhere is.

If you are weighing a subscription that includes search against building this yourself, what a mounted cloud drive costs at 3, 5 and 10 seats has the current rates with dates on them, and Frame.io Drive versus a self-hosted mount covers the newest mounted product in the category.

Sources, checked 16 August 2026

• Spotlight scope and Finder search over SMB: Synology Knowledge Center, File Indexing, Universal Search. Synology's guidance is that macOS Spotlight searches local files only, and that fully indexed shared folders mounted over SMB can be searched from Finder itself. The article body is rendered by JavaScript and could not be captured verbatim; the claim above is stated in our own words from Synology's published summary.
• QNAP Qsirch: qnap.com/en/software/qsirch and the Qsirch Quick Start Guide. Qsirch indexes NAS files in the background, searches filename, content and metadata, includes OCR of text inside images, and honours QTS permissions so users only find files they are authorised to see.
• Synology SMB browsing guidance: Synology Knowledge Center, What can I do to improve browsing experience when viewing files on Synology NAS via Finder on Mac?.
• macOS SMB directory caching: Apple Support, Disable local SMB directory enumeration caching, which documents the dir_cache_max_cnt setting in /etc/nsmb.conf and confirms macOS caches SMB directory enumerations by default.
• JuiceMount figures (filename search across roughly 131,000 entries, directory opens, cached reads): the performance page ledger and the public methodology in the app repository. Measured by the author on an Apple-Silicon Mac and TrueNAS SCALE over 10 GbE. Point-in-time author measurements on one Mac and one NAS, not independent benchmarks.