Seoul Labs

At 7,000 plus notes and roughly 50,000 links, a Dataview TABLE query that used to return in under a second started stalling long enough that I assumed Obsidian had frozen. The promotional pitch around PARA and Johnny Decimal in Obsidian treats the app as a complete system for notes, tasks, and projects, but it says nothing about query speed, link integrity, or sync once a vault crosses that threshold. I watched both organizing systems bend under real volume: a Templater script that silently filed eight months of notes into the wrong folder, a sync conflict that erased three days of a project log. Here's what actually breaks, and the fixes that held once the vault grew large enough to strain.

The source post making the rounds, from a writer going by Sébastien Dubois and tied to a paid Obsidian starter kit, makes a reasonable pitch: Obsidian is a complete system for knowledge, tasks, projects, and digital life, not just a note app. Fine as marketing copy. It skips the operational reality of running PARA and Johnny Decimal together at scale, though, and that reality looks like three specific failures: a query slowdown, a filing error, and a sync conflict.

The Threshold Where an Obsidian Vault Starts to Strain

I migrated a client's research vault from Notion to Obsidian in early 2025. As the note count grew, graph view got messy, though search stayed fast for a while. Then the Dataview plugin queries that used to return in under a second started taking noticeably longer on a mid range laptop. Past a certain size, with the links dense enough, certain Dataview TABLE queries against the full vault would stall long enough that I assumed the app had frozen.

Obsidian doesn't advertise this pattern, and it isn't really a bug. Dataview indexes your vault on load and re-indexes on changes. The cost scales with link count more than note count, because every backlink is a graph edge it has to track. A vault with heavy cross-referencing can end up with many links per note on average, and that density isn't unusual for someone doing serious PARA style cross referencing between Projects, Areas, Resources, and Archives. The query engine ends up walking a graph considerably denser than note count alone would suggest, which is why the slowdown showed up in query time long before it showed up anywhere else.

Here is a query that behaves fine on a small vault and visibly lags as the vault grows, especially combined with inline fields:

TABLE file.ctime as "Created", status, project
FROM "01-Projects" OR "02-Areas"
WHERE status != "done"
SORT file.mtime DESC

The fix that actually stuck, after trying folder based filters and tag based filters separately, was narrowing the FROM clause as aggressively as possible and avoiding OR conditions across top level PARA folders. Querying one folder at a time and combining results in a dashboard note cut re-index lag noticeably. Obsidian's own file index, separate from Dataview's, has improved in recent releases, but Dataview remains a community plugin with its own performance ceiling. That ceiling is where the PARA and Johnny Decimal combination starts to show its cracks, because the two systems disagree about something more basic than query performance: whether a note's location is supposed to change.

PARA and Johnny Decimal as Competing Rulebooks

Tiago Forte's PARA method, Projects, Areas, Resources, Archives, organizes by actionability. Johnny Decimal organizes by fixed numeric categories, usually two digits for an area and two for a category within it, like 21.04. Dubois's vault structure combines both, and on paper that sounds like the best of two systems: PARA for knowing what's active, Johnny Decimal for knowing exactly where something lives.

At low note counts, this combination feels great. At high note counts, the two systems start arguing with each other, because PARA assumes things move: a project becomes an archive the moment it's finished. Johnny Decimal assumes things stay put, since the whole point of the numbering scheme is that 21.04 always means the same category, and you build muscle memory around it.

I tried enforcing strict Johnny Decimal numbering inside PARA folders long enough for the failure mode to surface, and it was specific: when a project in 21.04 wrapped up and moved to Archives, did it keep its number or get renumbered under a 40-something Archive range? Keeping the original number preserved link integrity but broke the logical promise of Johnny Decimal, that the number tells you the category. Renumbering preserved the philosophy but broke every internal link pointing at that note, because Obsidian's link syntax by default references file paths or note titles, not stable IDs.

That last part matters more than most PKM guides mention. Use wikilinks like [[21.04 Client Onboarding]] and later rename the note to [[41.02 Client Onboarding]], and Obsidian auto updates the links inside your vault, which is genuinely useful. But any external reference, a saved search, a Dataview query hardcoded to a folder path, a Templater script, breaks silently with zero error message. You find out when a dashboard shows fewer notes than it should, and not before. That same silent failure, a broken reference with no error message, is exactly what took down eight months of filing when a Templater update changed how paths resolved.

A Templater Update That Broke Eight Months of Filing

Forty plus auto filing templates sounds appealing when you're staring at an empty vault. I built something similar for my own setup using Templater and a folder watcher script, and the part that never makes it into the promotional copy is what happens when a template references a plugin that updates its API.

At one point, a Templater update changed how tp.file.move() resolved relative paths in certain edge cases involving nested PARA subfolders, at least that's my best reconstruction of what happened. A template that had auto filed meeting notes into the correct Johnny Decimal category for eight months suddenly started dropping new notes into the vault root. No error, no warning. Notes just appeared somewhere unexpected, and I didn't notice until I went looking for one days later.

Here's a simplified version of the kind of Templater script that broke, trimmed down for clarity:

<%*
const area = tp.frontmatter.area || "00-Inbox";
const category = tp.frontmatter.category || "00";
const targetFolder = `02-Areas/${area}/${category}`;
await tp.file.move(`${targetFolder}/${tp.file.title}`);
%>

The script's logic wasn't the problem. tp.frontmatter read values before a YAML frontmatter template fully rendered in a specific plugin version, returning undefined instead of throwing, so the script fell back to the Inbox default every single time. Debugging this took longer than it should have because the first two things I checked, folder path syntax and the frontmatter YAML itself, were both fine. The actual cause was a timing issue in when Templater evaluated frontmatter relative to when Obsidian's own metadata cache updated. That kind of interaction only shows up once enough notes run through the pipeline daily for a pattern to emerge instead of looking like a one-off.

Forty templates is a lot of surface area for this kind of silent failure. Each one is a small contract with a plugin ecosystem that updates on its own schedule, not yours. A vault running at high note counts has usually been accumulating templates long enough that some were written for a plugin version two or three releases behind what's currently installed. That same gap, between how things are supposed to behave and how a specific plugin version actually behaves, is what turned a routine sync conflict into a real data loss problem next.

The Conflicted Copy That Erased a Project Log

A conflicted copy overwrote three days of a project log. That's what actually lost me data, not any of the structural issues above. It came from Obsidian Sync hiccupping during a conflict between two devices editing the same daily note simultaneously, something that happens more often than you'd expect once a vault is large enough that you're working from a laptop during the day and a phone in the evening, without always closing the app cleanly first.

Obsidian Sync keeps version history, and it works well, better than relying on a generic cloud folder sync for a vault with thousands of interlinked files, because file level cloud sync tools like a default Dropbox or iCloud setup can corrupt the links between notes if two devices write to the same file at nearly the same moment. But version history is a safety net, not a substitute for an actual backup strategy. I learned that the slow way.

What I run now, and what I'd tell anyone running a vault past a thousand notes to set up before they need it, is a scheduled git commit on the vault folder, separate entirely from Obsidian Sync:

#!/bin/bash
cd ~/Documents/ObsidianVault
git add -A
git commit -m "Auto backup $(date +%Y-%m-%d_%H:%M)" --quiet
git push origin main --quiet

Run that on a cron job every thirty minutes and you get a backup layer that doesn't care what Obsidian Sync or any plugin is doing. It's saved me more than once from exactly the kind of conflicted copy problem described above. It won't help with a renumbered Johnny Decimal category breaking a hardcoded Dataview path, though. Nothing fixes that except catching it fast, by checking dashboard note counts and link integrity on a regular schedule rather than waiting to stumble on the gap.

That's the actual answer to what the promotional pitch leaves out: past a few thousand notes, PARA and Johnny Decimal together don't fail quietly in one place. They fail in three different layers, query speed, filing logic, and sync, and each layer needs its own maintenance habit, not a one time setup. A vault that size isn't a system you install and trust. It's a system you check.