The folder structure that stops working at about 500 clips
A folder tree can only sort by one attribute at a time, and a clip has at least four you will later search by: when, where, who or what, and how it looks. The structure does not fail because you were careless - it fails because you asked a one-dimensional index to answer a four-dimensional question.
Published September 10, 2026 · Field notes
The moment it breaks is recognisable: you know you have the shot, you know roughly when you shot it, and you open four folders in a row without finding it. Nothing was done wrong. The tool ran out of dimensions.
The mechanism, in one paragraph
A file lives in exactly one directory. A clip, however, has at least four attributes you will later want to search by: when it was shot, where, who or what is in it, and how it looks - wide or tight, day or night, handheld or drone. Filing by one of those discards direct access by the other three. That is not a discipline problem you can fix with a better naming policy; it is the data model. Folders are a one-dimensional index over a four-dimensional object.
Small libraries hide this because you remember. Under a few hundred clips, you personally supply the missing dimensions - you recall that the harbour drone shot was the Tuesday of the Rotterdam job, so date is enough. What changes at scale is not the structure, it is that your memory stops covering the gap.
The three workarounds, and what each costs
Deeper nesting
2026 / 04-April / Rotterdam / drone / golden-hour. It feels like more dimensions and it is not: it is one path, so it only helps when you recall the attributes in that exact order, from the outside in. Get the third level wrong and you are browsing again. Deep trees also make ingest slower, which is when filing discipline actually dies.
Links and aliases
Symlinks, hard links and macOS aliases genuinely solve multi-axis filing: the clip can appear under drone and under Rotterdam. They also break on every drive migration, confuse backup tools into duplicating media, and require somebody to create one per clip per axis. This converts an occasional retrieval cost into a permanent maintenance cost, which is the wrong direction.
A spreadsheet
The honest one: a sheet with path, date, location, subject, rating. It works, and among people who answer these threads it is common. It has exactly one failure mode, and it is fatal - it is per-clip manual entry, so it stops being updated during the first busy month and after that you cannot trust a negative result. A half-maintained catalogue is worse than none.
What the shape of the fix has to be
Whatever replaces the tree has to satisfy three conditions to survive contact with real work:
- Multi-axis. The same clip must be reachable by date, by subject and by look, without picking one.
- Populated automatically. Anything requiring per-clip human entry decays. This is the condition spreadsheets and tag taxonomies fail.
- Non-destructive. It must not move, rename or re-file anything. Your tree, your relinks and your backups all depend on paths staying put.
That is the description of an index sitting beside the folders rather than a replacement for them. Keep the boring date-first tree - it is a good ingest structure, described in organising raw footage - and add the subject axis somewhere the tree cannot go.
How this works in Reelary
Reelary points at folders you already have, reads them in place, and never moves or renames anything. Removing a folder from the library removes the index entries, not the files. The subject axis comes from the picture: sampled frames are embedded by an on-device vision model, so you can retrieve by describing what was visible, while date, folder and file type stay available as filters. Colour and coarse scene categories fall out of the same vectors at no extra cost.
New files in a watched folder are picked up automatically, which matters for the maintenance condition - an index you have to remember to refresh is a spreadsheet with extra steps.
When not to use Reelary for this.
If your axis is one the picture does not contain - client name, contract status, usage rights, who approved the take - no visual index will help, and a spreadsheet or a proper MAM with custom fields is the right answer. If several people need to see the same catalogue, this is single-user. And if your material is long recordings rather than discrete clips, the 16-frames-per-video sampling cap means the index will be coarse; that limitation is described in visual search versus transcription.
Questions people ask about this
Why does my folder structure stop working as my library grows?
Because a folder tree is a single-axis index and a clip has several axes. Every file sits in exactly one folder, so choosing to sort by date gives up sorting by subject, and choosing subject gives up location. Below a few hundred clips you can compensate by remembering; above that, memory is the part that fails.
Do symlinks or aliases fix the one-folder-per-file problem?
Partly, and at a cost. Links let one clip appear in several places, but they break when files move between drives, they confuse backup and sync tools into copying the same media twice, and somebody has to create them by hand for every clip. They convert a retrieval problem into a maintenance problem.
Is 500 clips a real threshold?
It is a rule of thumb, not a measurement. The real threshold is where you stop being able to hold the library in your head - which arrives sooner with similar-looking material and later with distinctive shoots. What is precise is the mechanism: folders can only sort by one attribute, so the failure is structural rather than a matter of discipline.