First post. Grateful for such a curious and resourceful community of epistemological thinkers.
As a former long term Evernoter along with other PKMs, I have 30K of notes. I’ve discovered that a single vault isn’t very performance-minded and seems to fall into more of a monolithic design pattern vs. approaching the system as more of a distributed architecture. This becomes even more visible with the move to a mobile workflow.
As I embark on the challenges of building a multi-vault architecture, are there any design principles or practices that you’d recommend? I’m leaning towards using Obsidian URLs to reference documents across vaults.
Thank you for any hints.
1 Like
Decide on the specific purpose and function of each vault and allow each vault’s settings/plugins to evolve independently.
An example from my experience: I began with a single vault containing mostly a ZK. I started adding project management type capabilities to it. Since a ZK doesn’t lend itself to those types of things I needed a way to separate the concerns, so I started using folders. That eventually became a structure similar to PARA. But things still felt too tightly coupled. So I eventually moved all of my project notes out into a separate vault and physically separated the two concerns. Suddenly I found I no longer needed the PARA-type structure at all because using it was in fact an attempt to solve a problem incorrectly. By physically separating the two concerns they could become properly decoupled and evolve independently. The folder structure in both changed quickly to tailor down to each need, neither of which looks like PARA at all. And the plugin selection changed quickly as well. So did certain things like tag strategies. Items that I needed in one vault are completely unnecessary in the other. In my ZK I barely ever use tags but in my project vault I use tags all the time. Because it makes sense in that particular context and adds value.
So my overall point here is to think hard through the major functions of any vault you create, and try to group like concerns together and keep unlike concerns apart. Using URLs seems a good way to keep things loosely coupled between them when coupling may actually be needed.
Keep the coupling as loose as possible. Don’t have a workflow in one vault become overly reliant on the links or activity from another vault, and vice versa. You want to be able to adapt each vault independently. Let the URLs become a contract/interface between the concerns. Don’t tie functions too closely together between them. (this is a fundamental software design / systems design principle to enable parallel independent evolution of components, and it definitely applies here)
If you find many notes seem to span (be copied into) more than one vault then consider that as a signal that it may be best to create a new vault containing those notes and have the other vaults link to/from those notes instead of maintaining copies. (again, systems engineering refactoring concepts apply here)
There’s probably more but those seem like the big ideas off the top of my head. Avoid unnecessarily entangling concerns, keep like with like, communicate via standard pathways with standard protocols (i.e. the URLs) and enable independent parallel evolution of each vault.
2 Likes
I’m seeing something similar. I have an evergreen note vault where I added daily tracking which evolved into also tracking people and projects. Most of my navigation is via links, so the two never really mix. But the daily notes/people/projects probably expands 10x as quickly as the evergreen notes. I’ve been feeling a tug to pull them apart again.
(I stuck them together because the cost to switch vaults added too much friction when my vaults were smaller. No that they’re bigger, the vaults have enough of their own gravity to overcome that friction.)
1 Like
Yeah this is exactly why I started with them in a single vault and also exactly why I ultimately split them. Your point about the vaults having gravity is absolutely spot on, that’s exactly how it felt when I made the decision.
As soon as I did that they began rapidly changing and evolving into their own unique structures suited for their independent purposes. My projects vault now has a completely different structure and workflow than my ZK.
For example, the projects vault is primarily organized around the day while the ZK is organized around topic outlines (e.g. MOCs). There’s no daily notes at all in the ZK but in the projects vault there is one for every day. Meeting notes and “significant action” notes (important emails, decisions, etc) are tracked in notes right alongside the daily notes in a “Timeline” folder. All notes in the timeline folder start with the date in a particular format e.g. 21.05.May.03.Mon – meeting/etc notes then become 21.05.May.03.Mon (M) Discussion about blah blah. Within the note I include lots of links to people-specific notes, which in turn use dataview queries to generate lists of notes where they are included in specific fields or just mentioned.
None of that is in my ZK, which is very manual and focused on deeper knowledge and insight generation. Project vault holds things specific to things I do at work, not expected to be stored permanently. When they are no longer needed there the ones that are worth keeping will probably shift into my ZK. The ZK also holds concept & theory notes which are then used to help structure strategies & projects in the work vault.
There’s essentially zero links between them. A few times I mention a name in the ZK that is in the projects vault, but don’t link to it, and a few times mentioned in the project vault something like “see topic X in ZK” but that’s it.
2 Likes
Depending on my mood I use either Nebo or Notability on my iPad.
Nebo when I want to convert handwritten notes to text or when I just want to write something journal like I use Notability and export the PDF into my vault.
When you use the PDF and use the normal ISO date you can actually open the PDF directly from the calendar extension.
Sometimes I create a Markdown note which links to the PDF and includes the topics I was writing about.
1 Like