1 vs 2 Obsidian Vaults - How Many Should You Have?

TL;DR

Start with one Obsidian vault, then add more only when there’s a clear workflow need rather than by default.

Briefing Cornell Notes

Briefing

The central takeaway is that Obsidian users don’t need to choose “one vault or many” as a rule—vault count should match how much their notes need to connect, and how much performance and interface complexity they can tolerate. A single vault keeps everything linkable and avoids constant switching, but it can also create a cluttered graph and slowdowns as unrelated note sets grow. Multiple vaults, by contrast, can isolate workflows (like Zettelkasten, programming, or writing) so the graph stays meaningful, the UI stays responsive, and each workspace can run with a tailored plugin and layout setup.

Support for one vault starts with the “one brain, one vault” idea: if Obsidian is a second brain, then all knowledge should live together. The practical downside shows up in graph navigation. When a large portion of notes never link to the rest—common with Zettelkasten-style notes, journals, or other siloed systems—the graph becomes dominated by disconnected clusters. One workaround is to open a single folder “as a vault,” effectively treating a subset of notes like its own vault without fully committing to multiple vaults. This can reduce distractions and improve responsiveness, especially when the main vault becomes very large.

Another argument for one vault is workflow simplicity: cross-referencing between notes is straightforward because everything lives in the same vault. With multiple vaults, direct linking across vault boundaries isn’t possible, so users must rely on manual navigation (for example, using a link pattern like “double brackets vault/ note name”) and then switching to the other vault to find the target.

The case for two or more vaults becomes strongest when note sets are intentionally disconnected. If Zettelkasten notes rarely need to link to MOCs, journals, or other project notes, keeping them in the main vault can waste graph space and reduce clarity. The same logic applies to programmers separating work: code notes often link heavily within their own ecosystem, while referencing mindfulness journals or unrelated personal notes is unlikely. Students can also benefit by giving each subject its own vault—except for courses with continuity (like Calculus 1 and 2), where links between semesters are useful.

Multiple vaults also help with performance. As vault size grows into the multi-gigabyte range with thousands of nodes, responsiveness can degrade. Splitting into separate vaults reduces what must load and render at once. It also enables UI personalization: different vaults can run different plugins, hide irrelevant panels (like a calendar), and support different layouts or future custom CSS.

A concrete example comes from a user who moved from one vault to three: a main vault for daily journaling and curated content, a dedicated Zettelkasten vault to prevent a disconnected graph cluster and improve speed, and a programming/work vault created when programming notes became heavily internally linked but disconnected from the rest. Looking ahead, the user is interested in a shared vault for collaboration, noting that shared access can be implemented either as a separate vault or as a shared folder within a larger vault (e.g., via cloud storage permissions). The recommendation lands on starting with one vault and adding more only when there’s a real need—especially when the need is isolation for workflows that don’t require cross-linking.

Cornell Notes

Obsidian vaults should be organized around how notes relate and how much isolation improves clarity and performance. One vault supports seamless linking and reduces switching, but it can produce a graph dominated by disconnected clusters and can slow down large vaults. Multiple vaults help when workflows are largely self-contained—like Zettelkasten, programming projects, or writing universes—so the graph stays meaningful and the UI can be tailored with fewer plugins and different layouts. A practical workaround for some “multiple vault” benefits is opening a folder as a vault, which isolates a subset without fully restructuring everything. The best approach is to start with one vault and add others only when there’s a clear need, since many people later revert back to one.

Why do disconnected note clusters make a single-vault setup feel worse over time?

When a large portion of notes doesn’t link to the rest—common with Zettelkasten notes, journals, or other siloed systems—the graph view becomes dominated by an isolated cluster. That makes navigation less useful because the graph’s most visible structure doesn’t reflect meaningful cross-connections. It can also contribute to slower performance as the vault grows, since everything still loads together.

What’s the key tradeoff when moving from one vault to multiple vaults?

The tradeoff is linkability versus isolation. Notes in different vaults can’t be linked directly, so cross-vault referencing requires manual navigation (for example, using a “double brackets vault/ note name” style link and then switching vaults). In return, multiple vaults prevent unrelated workflows from cluttering each other’s graph and can improve responsiveness.

How can users get some benefits of multiple vaults without fully creating them?

A workaround is to open a specific folder “as a vault.” For instance, placing biology notes in a single folder and opening that folder as a vault lets the user view only that subset, reducing distractions. This can also help when a large vault slows down the app, because the isolated view loads less data.

When does splitting into multiple vaults make the most sense for students?

Splitting by subject works well when each subject’s notes don’t need to connect. The exception is classes with continuity—like Calculus 1 and Calculus 2—where links between earlier and later material are valuable, so those courses may belong in the same vault.

What performance and UI advantages come from multiple vaults?

Large vaults (multi-gigabyte, with thousands of nodes) can become less responsive. Separating into multiple vaults reduces what must load and render, improving responsiveness. It also allows different plugin sets and UI layouts per vault—such as hiding a calendar panel and giving the local graph more screen space—plus the option to change themes or custom CSS later.

How does collaboration fit into the vault strategy?

Collaboration can be handled through a shared vault or a shared folder inside a vault. Instead of building a brand-new vault, users can create a dedicated shared folder and grant access via cloud storage permissions (e.g., Dropbox or Google Drive). That enables multiple people to contribute to a single shared knowledge base, such as a class project.

Review Questions

In what situations would a disconnected Zettelkasten cluster be a stronger reason to split vaults than a reason to use folder-as-vault?
What cross-vault referencing method would you use if direct linking isn’t available, and what workflow friction does it introduce?
How would you decide whether Calculus 1 and Calculus 2 should be in the same vault or separate vaults?

Key Points

1
Start with one Obsidian vault, then add more only when there’s a clear workflow need rather than by default.
2
Use a single vault when cross-referencing across note types is frequent and direct linking matters.
3
Consider multiple vaults when major note sets are intentionally siloed and would otherwise create disconnected graph clusters.
4
Open a folder as a vault to isolate a subset of notes without fully committing to multiple vaults.
5
Split vaults to improve responsiveness when the main vault becomes very large (multi-gigabyte with thousands of nodes).
6
Tailor plugins and UI per vault when different workflows need different layouts or fewer distractions.
7
For collaboration, share a dedicated vault or—often more simply—share a specific folder within a vault via cloud permissions.

Highlights

Multiple vaults shine when workflows don’t need to connect—otherwise the graph becomes cluttered with disconnected clusters.

Direct linking across vaults isn’t available, so cross-vault referencing requires manual navigation using vault-aware link patterns.

Performance can degrade in very large vaults, and splitting reduces what must load and render at once.

Folder-as-vault is a practical middle ground that isolates content without restructuring everything.

Shared work can be implemented by sharing a folder inside a vault, not necessarily by creating a separate vault.