The 10,000-Note Question, Answered Honestly: What Note Apps Actually Say About Large Vaults (and the One Number We Could Measure)

No mainstream note app publishes a maximum number of notes per vault. Across nine surveyed apps, every stated ceiling is per-file or per-page, not per-count — Notion caps file size, Logseq paginates blocks, Standard Notes flags oversized notes. And a plain folder of 10,000 Markdown files, searched with no index, returns matches in roughly 50 to 70 milliseconds.

That last number is the only speed we measured ourselves, and we are careful about it. We built a deterministic corpus — 10,000 Markdown files, 43.93 MB, an average of 4.50 KB per note — and searched it with ripgrep, cold, five times per query. A rare term matched in as little as 46 milliseconds; a common one in 67.¹ It is a sandbox figure on a single machine with a warm cache, so treat it as an order of magnitude, not a leaderboard entry. The rest of this post is not a race. No one ran ten apps side by side on identical hardware, and we will not pretend otherwise. What we can do honestly is three things: report what each vendor actually publishes about large vaults, show the one number we could reproduce, and explain the architecture that decides whether note count ever becomes a wall.

Is there a maximum number of notes a vault can hold?

No surveyed note app publishes a maximum note count. We checked nine — Notion, Obsidian, Logseq, Joplin, Standard Notes, Bear, Zettlr, VS Code, and Anytype — and not one names a ceiling on how many notes a vault may hold. The numeric limits that do exist are about the size of a single file, not the number of them.

This is the finding most listicles miss. Search "note limit in [app]" and you will find forum threads, support tickets, and a lot of guessing, but no published number, because the vendors do not set one. The ceilings they do document are structural: how large one file can be, or how many blocks one page renders at once.

That distinction is the whole story. A vault of 10,000 tiny notes and a vault of ten enormous ones are treated very differently by every app we looked at. The count is not the variable the vendors track. The size of each unit is.

What size limits do note apps actually state?

The published ceilings fall into two buckets. Per-file limits cap how big one attachment or document can be: Notion allows files of up to 5MB each on its free plan and 5GB on paid,² and Bear sets a general limit of 250MB per attachment.³ VS Code degrades features on any file over 30MB.⁴

The second bucket is per-page and per-note structure. Logseq renders in paginated chunks. Standard Notes recommends a soft cap on the size of a single note because of how it processes each edit. Neither is a limit on how many notes you keep — both are limits on how big one unit gets before the app changes behavior.

VS Code is the clearest published example of a per-file threshold. Its release notes state that "any file that is over 30MB or over 300K lines will now be considered a large file and will be handled specially in some circumstances. By disabling certain features for large files, for example tokenization, line guides, and wrapping or folding" it reduces memory pressure.⁴ The limit is the file, not the folder — and on 64-bit machines there is "no size limit" at all beyond that degrade threshold.⁴

Standard Notes is the clearest per-note example. Its help center says the app "doesn't have any hard limits on data size," but warns "you may run into performance issues if your notes are too large," because "every change you make to a note runs through encryption algorithms on your device." Its recommendation: "no larger than 1MB of text per note, which for text-based content, is a lot of text."⁵

Here is the same evidence as a table. Every cell is the vendor's own published statement — no speed we invented, no ranking:

Anytype, the ninth app we checked, publishes no note-count limit either. Not one row in this table is a number of notes.

Does a large vault actually make a note app slow?

Not by note count alone, according to the vendors themselves. Several actively reject the premise. Joplin's creator says notebooks and note counts are not really an issue, and that some users already hold millions of items. Obsidian's team told a user that 1,000 notes is not even a large vault. Slowdowns, they say, come from other things.

Laurent Cozic, who created Joplin, put it plainly on the project's own forum: "Number of notes or notebooks is not really an issue as far as I know, since the UI is optimised to handle this. For example the note list can load thousands of notes without problems. … in practice some users already have millions of items or more and it works fine."⁸

Obsidian's team is blunter still. When a user described a "large vault," a moderator carrying the Obsidian Team badge replied: "1000 notes I would not call this a large vault. Try with restricted mode."⁷ The nudge toward restricted mode is the tell — it disables community plugins, because plugins, not notes, are the usual culprit. In the same thread, a power user reports: "I have over 23,000 journals alone, not including all the PDFs, images, and none-journal notes, and things generally work well. Dataview is defintely one to look out for."⁷ Twenty-three thousand notes, working well, with one plugin flagged as the thing to watch.

Even the apps that do document a structural limit name a cause that is not count. Logseq's founder, Tienson Qin, explaining sluggish large pages: "we use the pagination to render 200 blocks per page, but for a very long page, we need to improve the datalog query performance too."⁶ The pain is blocks on one page and query cost — not the size of the graph.

Zettlr's maintainer, debugging a slow vault, reached the same kind of answer: "I'm pretty sure it's not because of the folder depth. We've had the problem in the past that sometimes, rogue .ztr-directory-files were causing problems."⁹ Case by case, not a global ceiling.

The pattern across every vendor is consistent. The named causes of slowdown are attachment size, single-note size, on-device encryption cost, plugin and query load, and where you put the sync folder. Note count is on nobody's list.

How fast is a plain folder of 10,000 notes?

Fast enough that note count is not the bottleneck. On our deterministic 10,000-note, 43.93 MB corpus, ripgrep — an index-free, line-oriented search that scans every file cold — returned full-corpus matches in roughly 50 to 70 milliseconds: a rare term in 46 to 65 ms, a common term in 65 to 75 ms.¹

This is the one number we measured ourselves, and the honesty about it matters as much as the number. It was run in a single sandbox, on one machine, with a warm page cache and no drop_caches between runs. So it is an order-of-magnitude reference, not a publishable leaderboard figure: the kind of cross-app table that would need constant hardware, which we do not claim to have run. What makes it useful is that it is reproducible: the corpus is byte-deterministic from a fixed seed, and the command is one line.

# Generate the exact 10,000-note / 43.93 MB corpus, then search it cold.
N=10000 OUT=./vault node generate-corpus.js
RG=$(command -v rg) V=./vault ./ripgrep-baseline.sh

The reason this matters is what it does not do. There is no index to build, nothing to keep warm, and no reopen cost after a restart. ripgrep, in its own words, "is a line-oriented search tool that recursively searches the current directory."¹⁰ It reads the files and answers. A folder of Markdown has no scaling wall of the kind users fear, because the work is proportional to bytes scanned, and 44 MB of text is small. The interesting question is not whether a folder is fast. It is why some apps, doing more than a folder, get slower — and that is architecture.

Why does architecture decide scale, not note count?

Because the cost that grows with a vault is not the number of notes — it is what the app rebuilds every time it opens one. An app that keeps a live index answers instantly; an app that re-scans a folder pays for size on every query. Note count is a proxy; architecture is the cause.

We benchmarked exactly this trade-off in a companion post on browser storage, where the difference between reading from a maintained index and re-scanning raw storage is measured directly. The same logic governs a note app: a maintained index turns "search 10,000 notes" into a lookup, while a naive re-scan turns it into work that grows with the corpus. Our sibling benchmark of in-browser full-text search shows how much a purpose-built index buys you on the browser side of that line.

The research tradition names the same ideal. Ink & Switch's Local-first software essay argues that software should feel instant, with your work at your fingertips and no waiting on a server round-trip, and should still be readable years from now.¹¹ Speed and longevity are treated as design properties you build in, not luck you hope for. An index in the browser is one way to buy the first; plain files are how you buy the second.

This is where the honest per-op cost lives. Standard Notes is slow on huge notes not because it holds many, but because "every change you make to a note runs through encryption algorithms on your device."⁵ The cost is per-edit, per-note: an architectural choice, priced on every keystroke. Every app makes trade-offs like this. Reading the trade-off tells you where the wall is far better than counting notes does.

For our part, MNMNOTE keeps notes as plain Markdown on your own device and answers search from a browser-local index rather than re-scanning the whole folder on every query: the architecture, not a note ceiling, is what we design around. As Steph Ango, Obsidian's CEO, writes: "Apps are ephemeral, but your files have a chance to last."¹² The count of your notes is a story about today. The shape of how they are stored is the part that decides whether they are still fast, and still yours, in ten years.

Who should worry about vault size — and who should not?

If your vault is thousands of plain-text notes, size is not your problem — several vendors say so outright. Worry instead if you store huge attachments, keep single files in the tens of megabytes, or lean on heavy live queries and plugins. Those are the costs vendors actually name, and none of them is note count.

You should watch vault behavior if you:

• Store large media — Notion caps files at 5MB free, Bear at 250MB per attachment.²³
• Keep enormous single documents — VS Code degrades on files past 30MB or 300K lines.⁴
• Write very long, dense notes — Standard Notes recommends staying under ~1MB per note because each edit is re-encrypted.⁵
• Depend on heavy live queries or many plugins — the Obsidian team's own advice is to test in restricted mode.⁷

You do not need to worry if you:

• Keep thousands of ordinary Markdown notes — Joplin's creator: "some users already have millions of items or more and it works fine."⁸
• Search a plain folder of text — an index-free scan of 10,000 notes finished in ~50 to 70 ms in our test.¹
• Value portability over a single vendor's index — plain files carry no per-app ceiling with them.

Frequently asked questions

These are the questions people actually type when a vault grows past a few thousand notes. The short answer to most of them is the same: the number of notes is rarely the variable that matters. Here is what the vendors' own documentation and our one measured baseline say about each.

What's the note limit in Notion, Obsidian, or Logseq? None of them publishes a maximum note count. Notion's documented limit is per-file — 5MB each on free, 5GB on paid.² Obsidian publishes no vault-size ceiling; its team says 1,000 notes is not even "large."⁷ Logseq's structural limit is per-page: it renders 200 blocks per page.⁶

Does Obsidian slow down with a large vault? Not from note count, per Obsidian's own team, who call 1,000 notes not a large vault and point to restricted mode.⁷ One community user runs "over 23,000 journals … and things generally work well," flagging the Dataview plugin as the thing to watch.⁷ Plugins and sync-folder placement drive slowdowns, not the number of notes.

How many notes can Joplin or Standard Notes hold? Joplin publishes no practical limit; its creator says "some users already have millions of items or more and it works fine."⁸ Standard Notes also sets "no hard limits on data size," but recommends "no larger than 1MB of text per note" because each edit is re-encrypted on your device.⁵ Both cap unit size, not count.

Why is my note app slow with lots of notes? Usually not the count. The causes vendors actually name are per-item size, plugin and live-query load, on-device encryption cost, available RAM, and where the sync folder lives.⁵⁶⁷ A vault of many small notes rarely triggers any of these; a few enormous files or a heavy plugin often does.

Is a folder of Markdown files fast to search? Yes, in our test. A plain folder of 10,000 Markdown files (43.93 MB), searched cold with ripgrep and no index, returned full-corpus matches in roughly 50 to 70 milliseconds.¹ There is no index to build and no reopen cost. Treat the exact milliseconds as order-of-magnitude — single machine, warm cache — but the shape holds: text folders do not hit a note-count wall.

Did you benchmark ten apps at 10,000 notes? No, and we will not imply we did. We measured one reproducible baseline — the index-free folder scan above — and surveyed what each vendor publishes about large vaults. A cross-app table on identical hardware needs a controlled machine we did not run this on; it is deferred, not faked. Every number here is either a vendor's own or one we actually measured.

The 10,000-note question has a quieter answer than the forums suggest: the vault is almost never the thing that slows down. What slows down is everything an app does around your notes — the indexes it rebuilds, the plugins it runs, the media it carries. Count is a story we tell; architecture is the fact underneath it.

MNMNOTE keeps your notes as plain Markdown on your own device and answers search from a browser-local index rather than re-scanning a folder — you can open a tab and start writing at mnmnote.com.