Stop Filing, Start Finding: Search Beats Folders

If your notes are plain text on disk, you need not file them into the perfect folder. Your filesystem plus a tool like grep or ripgrep is already a full-text search engine that needs no index to build and no app to launch. Retrieve by searching the words you remember, not by guessing the folder you chose months ago.

This is a claim about a mechanism, not a philosophy. The argument for writing first and not over-organizing is made elsewhere; this post is about the retrieval layer underneath it. The mechanism is old, fast, and standardized: POSIX defines grep as a utility that shall "search the input files, selecting lines matching one or more patterns" ¹, and it ships on every Unix-like machine you own. The honest catch — a real recall ceiling at scale — gets its own section below.

How does full-text search actually find a note?

Full-text search reads the words inside your files directly and returns every line that matches a pattern. There is no separate catalog to maintain. POSIX grep is defined simply as a tool to "search a file for a pattern" ¹; ripgrep "recursively searches the current directory for a regex pattern" ². You type the words; the tool reads the files.

That is the whole model. A folder hierarchy asks you to predict, at filing time, the single place you will later look. Search asks nothing in advance — it scans the actual contents at the moment you need them. For plain Markdown notes, the contents are the index. The only precondition is that your notes be readable text, which is exactly what a .md file is.

Why search a whole directory instead of building an index?

Recursive search needs no persistent index to maintain, so there is nothing to rebuild, corrupt, or wait on. ripgrep "recursively searches the current directory for a regex pattern" and "will respect gitignore rules and automatically skip hidden files/directories and binary files" by default ². You point it at your notes folder once; it walks every file underneath, every time, fresh.

Compare the two costs honestly. An indexing approach pays up front: it builds and stores a catalog, then keeps it in sync as files change. Recursive search pays at query time, reading files on demand. For a personal note vault, the at-query cost is small and the maintenance cost is zero. The number that makes this concrete is the speed.

Is searching a large notes folder fast enough?

Yes — on plain text, recursive search is effectively instant at personal scale. In Andrew Gallant's published benchmark, ripgrep searches the entire Linux kernel source tree for [A-Z]+_SUSPEND in 0.082 seconds, faster than git grep's 0.273s on the same run ³. That is a codebase far larger than any note vault, scanned in a fraction of a second.

Two caveats keep this honest. That 0.082s figure is Gallant's own measurement on an Intel i9-12900K, not a number you should quote as your own — hardware varies, so the durable claim is the ratio and "sub-second on a huge tree," not the absolute time. And the speed is a property of the tool reading raw text, not of any one note app. The point stands either way: for a few thousand Markdown files, the wait is not the bottleneck.

Why is this so durable — search vs the app's own search box?

Because the search lives in your operating system and your files, not inside one program, it outlives any single app. POSIX grep is a 40-year-old standardized utility ¹; ripgrep, in Gallant's words, "can replace many use cases served by other search tools because it contains most of their features and is generally faster" ⁴. Neither needs your note app.

An in-app search box is genuinely convenient, and most people will reach for it first. But it works only while that app runs, and its private index disappears when the app does. A filesystem search does not. This is the same logic Obsidian's Steph Ango captures in his "file over app" idea: "File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read" ⁵. Plain text makes your retrieval portable, not just your writing. As Ango puts it, "Apps are ephemeral, but your files have a chance to last" ⁶.

Which search tool should you use?

Pick the tool that matches your comfort, not the most powerful one. Terminal users get the fastest, most precise option; everyone else has a built-in graphical path that searches file contents without a single command. The capability is the same underneath — read the words in the files and return the matches.

If you have never opened a terminal, start with your operating system's search and your app's own search box — both already index file contents. The terminal tools are an upgrade in speed and precision, not a prerequisite. A one-line recursive search looks like this:

# search every .md file under your notes folder for "mitochondria"
rg -i "mitochondria" ~/notes

# the same idea with POSIX grep, recursive, case-insensitive
grep -ri "mitochondria" ~/notes

Does how you retrieve change how you should write?

It should. A 2025 case study of professionals using a Markdown vault found that "participants' knowledge retrieval strategy influences how they build and maintain their content" ⁷. If you retrieve by searching, write so your future search terms are in the note — name the thing, repeat the keyword, spell out the acronym once.

This flips the usual order. Instead of designing a folder taxonomy and forcing each note into it, you write the note plainly and let the words be the handle you grab later. The structure that matters is not the tree above the file; it is the vocabulary inside it. Which is exactly where search starts to fail — and where the honest caveats begin.

Where does search fail? The recall ceiling

Search has a real limit: you cannot find a note whose words you cannot recall. The classic evidence is the Blair and Maron study, recounted by Tiago Forte. Early full-text enthusiasts "happily proclaimed the 'death of meta-data'" ⁸ — why pay humans to index documents when the computer could just search everything? Then the measurements came in.

On a large legal collection, "Blair and Maron showed that recall averaged only about 20%" — "the system was retrieving only about 1 in every 5 relevant documents," and that was with trained researchers ⁹. The cause was not weak computers. As Forte summarizes the finding, "it was a language problem, not a computer problem" ⁸. People searched for the words they expected; the documents used different words. Search only finds what you can name.

Who should NOT just search everything

Search-only retrieval breaks down for a few real cases — name them before you commit to the approach. Notice that the villain is deep, over-built taxonomy you must maintain, not all structure. A little structure, in the right place, raises recall instead of costing you maintenance.

• You routinely forget the words. If you search for "that article about focus" and your note says "deep work," you will miss it. The fix is not deeper folders — it is better filenames. A descriptive filename is a search handle you control, which is why naming the file well matters more than nesting it. (See our guide to naming your note files.)
• Your notes are not plain text. The whole durability argument depends on the notes being readable files. Search a proprietary, encoded format and you are back inside one app's index, which leaves when the app does.
• You need an overview, not a hit. Search answers "where is the note that says X," not "what do I know about Y." For that, one hand-written index note beats any query — a single page that links the few notes that matter. This pairs with the tags-vs-folders decision, where search is the third option to weigh against both.

What about the "you can only hold seven things" rule?

Deep folder trees strain working memory, but be precise about why. George Miller's 1956 paper found "this span is about seven items in length," describing immediate memory, "a finite span of immediate memory" for test materials ¹⁰ — not a law that folders may be seven deep. Treat it as a reason nested hierarchies feel heavy, not a rule.

The practical reading is modest and defensible. The more levels and siblings a tree has, the more you must hold in mind to decide where a note goes and where it later hides. Search removes that bookkeeping for the common case. Structure earns its keep only where it raises recall — a good filename, one index note — and stops earning it the moment it becomes a tree you maintain for its own sake. That balance, and not "never organize," is the takeaway. The philosophy behind it lives in stop organizing, start writing.

Frequently Asked Questions

Should I use folders or search for my notes?

For plain-text notes, lead with search and keep folders shallow. Your filesystem plus a tool like grep or ripgrep reads the words inside every file with no index to maintain. Use a little structure — good filenames and maybe one index note — only where it raises recall, not as a deep tree you must constantly tend.

How do I full-text search my notes from the terminal?

Run a recursive search from your notes folder. With ripgrep: rg -i "your phrase" ~/notes searches every file underneath, case-insensitively, respecting .gitignore. With POSIX grep: grep -ri "your phrase" ~/notes does the same. Both read file contents directly, so there is no index to build first and nothing to keep in sync.

Do I need to know the command line to search my notes?

No. Your operating system's built-in search (Spotlight on macOS, Windows Search) indexes file contents, including plain-text and Markdown, and searches them from a familiar box. Your note app's own search works too while the app is open. Terminal tools like ripgrep are a speed-and-precision upgrade, not a requirement.

Why is searching plain-text files so fast?

Because reading raw text is cheap and modern tools are highly optimized. In Andrew Gallant's published benchmark, ripgrep searched the entire Linux kernel source tree in 0.082 seconds — a codebase far larger than any note vault. The exact time depends on hardware, but the durable point holds: at personal scale, recursive full-text search is effectively instant.

When does search fail to find my note?

When you cannot recall the words the note actually uses. The Blair and Maron study found full-text recall averaged only about 20% on a large collection — "a language problem, not a computer problem." If your search terms and your note's wording diverge, you miss it. Descriptive filenames and an occasional index note are the fix, not deeper folders.

Is search a reason to never organize my notes at all?

No. Search replaces deep, maintenance-heavy taxonomy, not all structure. A descriptive filename is a search handle; one index note gives you an overview a query cannot. The honest position is to keep the small amount of structure that raises recall and drop the elaborate trees that only cost you upkeep.

A folder is a bet you place once, about a future you cannot see; a search is a question you ask the moment you need the answer. This argument builds on Steph Ango's "file over app" idea — keep your notes as plain files, and the act of finding them outlives any app. To keep notes that way, mnmnote.com stores everything as plain Markdown on your own device, where your filesystem and any search tool can already read it.