Nested vaults - usage and risks

The developers strongly advise against any use of nested vaults, warning that the program is not designed to cope with them and things may break.

(Nested vaults are vaults located within another vault. As with any folders, It is possible to have many layers of vaults.)

They do however, have some uses:

  • They allow the same vault to be open in more than one window.
  • They allow sub-folders (aka nested vaults) to use a different CSS to other vaults, and to have its own saved workspace etc.
  • They make it easier to focus on the material in the nested vault without being distracted by other files and folders.
  • They are very useful for projects where most of the sources and writing is project specific.

To a vault at the top of the hierarchy, the vaults nested within simply look like folders, and all normal Obsidian functions are possible.
The nested vaults beneath cannot see, or be aware of, vaults above or to the side of it in the folder hierarchy.

My preferences, based on observations thus far, are:

  1. Avoid nesting a vault unless the gain from having one is clear.
  2. Editing and linking at the top level should be safe for everything.
  3. Unique file names are essential - but clashes may not be pointed out in a lower level vault - so have another way of checking uniqueness if creating new files in a nested vault.
  4. Using links in a lower level vault is likely to lose data except when the links used are all within the vault. If you try to use a link to a file in another vault, it cannot be found and can trigger the creation of a new file of the same name within the vault. Therefore only use and make links with files in the vault.
  5. Conversely, it is best for each vault to have its own attachment folder. This keeps everything relevant in one place, making it easier to manage from the OS file system and works perfectly well from higher level vaults.
  6. There is no risk when a nested vault is used only in preview mode; this can be useful when you want to read in one window and write in another.
  7. Have a robust backup routine.
  8. Have programs that can compare files in folders and identify changes - if there’s a problem, version control ala Dropbox etc may not be sufficient to recover the situation.
  9. They work best where the material in the nested vault has little interaction with other vaults. Little but not none - if it were none there would be no reason for it not to be a completely separate folder. And a lot of interaction means it would be better to have access to them all.

I don’t use markdown links and I use shortest path (usually) - I can see that either of those might make a difference.

I would be keen on corrections, additions and observations. This is a topic rarely discussed, presumably to avoid encouraging users to do something inherently unsafe. Equally, I’m aware that a number of people use the technique, so establishing safe boundaries and known risks may be useful.

6 Likes

Interesting, I was thinking about the opportunity to use a nested vault for the publish thing, so I check the graph on the nested vault and see only the links pertaining to the published material and at the same time to link some content in the nested public vault from my private top level vault that I would use for organizing my work.What do you think, it is something than can work?

1 Like

Depends on whether I understand you properly.

Boundaries around each vault are impenetrable.
So the nested vault can’t link to anything in your top level vault.
But
When you are in your top level vault, the nested vault is only a folder so you can link all you want.

I don’t have Publish, so can’t test, but if I understand you right it should work.

1 Like

Yes it’s exactly what I was trying to say, but my bad English doesn’t help. From what you said it seems that could work and could be also a perfect solution for my use case. Thanks a lot for giving me some inspiration!

1 Like

Pefect, thank you for putting this together @Dor I’ve been doing this, but wasn’t aware of some of the cautions to take.

backing things up with git version control is perhaps the most important thing to do, specially when testing this kind of stuff.

to point out what @madz00 said

In future versions of obsidian will this nested vault approach become a more frequent practice?

when I got obsidian publish, I found the nested vault the only clean approach to only publish one sub-folder of notes. I can imagine this becoming the best practice for obsidian publish, unless there’s something I’m missing

What do current users of obsidian publish think about this?

1 Like

I’d like it if it was, but so far Licat has advised against doing it. I assume there’s ways of protecting against some or all of the risks, but I don’t know.

The firm barrier around each vault brings advantages as well as disadvantages.

2 Likes

got you, I’ll keep an eye for any news on this, I suspect things will change, specially as obsidian publish grows.

thanks again for the help

oh god thank you so much for listing all of this out. playing with fire

2 Likes

Quick update which I’ll add to first post.

They are very helpful for projects.
For instance, academic research or papers with a mix of broader (intro, discussion) and deeper (experiments). All the deeper is most effectively done within the project vault and the broader can be added and linked from a higher level vault. Once the project is completed, the project vault just becomes a sub-folder unless it is ever needed again.

Have an attachment folder for each vault. This keeps all vault specific attachments in a sub-folder which makes it easier to access and manage from the OS file system should that ever be needed. All the attachments and links are accessible from both the nested vault and higher level vaults.

I also noted the reference with the new block links that using ^^ might be slow in massive vaults. Nested vaults would be one way of managing this where only a smaller and specific group of files needed to be searched for potential linking.

3 Likes

@Dor, thank you so much for this relevant post. This post, written by @santi, is also relevant to this discussion.

I’ve been using (and marvelled at, not gonna lie) Obsidian for the last two weeks. One of the first thoughts I had was precisely using nested vaults, which I quickly dismissed while learning about the software in its Help Vault.

Having read your 9 tenets for using nested vaults, I totally agree with them and I believe they’re exactly what we need to use them correctly. Nested vaults should only be used when there is a specific reason for them. That excludes any situation where you can just have a separate vault to develop a set of notes, as you can just take them at the end of the process and integrate them into the main vault.

The only reason to use this is indeed to have some usefulness in compartmentalizing a set of notes even after developing them (so you can keep a separate graph and set of tags, backlinks, linked mentions, etc.) while also having the possibility of integrating references to those notes in another higher-level vault.

In my case, I started with the main vault where I tried to integrate various sets of notes. My main vault’s primary purpose is for me to keep track of my corpus of knowledge, so to speak, so it includes many different types of information.

To keep it organized, I use various strategies that are synergetic with each other:

  1. I use folders as a way of separating sets of notes by hard functionality (e.g. “Templates”, “Daily Notes”, “Fleeting Notes”, “Literature Notes”, “Permanent Notes”, “Concepts”, “Facts”, “References”, “[name of some project with various kinds of notes all related to it]”, etc).

    • Do not underestimate the value of folders. These are handy for when your vault becomes too big and you can just move them around, extract a set of notes from the file explorer to a USB or another location, etc. This is important, and I believe those who use a flat hierarchy might lose a valuable hard organization of their notes which would facilitate the manipulation of the containers of their notes, i.e. their files.
  2. I use two different sets of tags meant to let me view notes according to some parameters. In each note, they are written at the foot of the note as such:

    Tags: [Tags about a note’s functionality] | [Tags about the note’s contents]

    The first kind is something like #Diary, #Definition or #Connection. It’s meant for me to be able to see notes with a specific functionality inside obsidian. But these tags don’t exclude the value of folder division by functionality, as you can see by the examples I gave above. The second kind of tags is about its contents, such as #Alchemy, #Friedrich Nietzsche, #Philosophy, #PKM, #Practicalities, etc.

  3. Indexes, MOCs, and all the kind of extra meta-notes are also useful in vast vaults, and you can even aggregate them in their own folder for easy access (without the need to mess with the names of the files themselves).

    3.1 This also comes in handy for naming the notes. I use a similar strategy to @lizardmenfromspace, which he/she details here. This has not only the advantages he/she explores in that entry, but also lets me search specifically for a few things. For example, the format of the UID for my notes is generally “YYYY.MM.DD-HH.MM”, after which I write the note title. This lets me search for the notes I’ve written on a given month or a given year (if I search for “2020.10”, for example, I see the notes I’ve written during october, which is something you can’t do with tags, as they can’t be numbers), while guaranteeing redundancy and also letting me use the note title to link (if I write “[[note title”, I’m suggested the note by obsidian while I’m writing, even if I don’t use its UID). The only thing I’m missing is really the ability to use unlinked mentions, and I really hope obsidian devs address this issue. It would only need to recognise partial filenames of the files and use them as unlinked mentions, especially if this were restricted to excluding well-known sequences present therein such as UIDs, Luhmann IDs, etc.

    3.2 I also think that the headers are a great way of organizing information that you can refer to specifically without the need of a new note (atomicity is important, but should not be the only strategy employed, especially when you have ideas you want to compartmentalize but are too interrelated to be separated from each other) and, with 0.9.5, blocks.

While all these strategies work well within a vault, what if I want to use a more streamlined process specifically for a concept I’m trying to develop? That’s where nested vaults are particularly handy. I can use a nested vault where I only use stripped-down note titles without the need to fit in my workflow mentioned above to develop the concept/project. I can have the benefits of a separate graph view, tags, mentions, etc, while also being able to integrate it in the main vault and make use of the extensive reference system between notes.

Don’t forget: the notes inside a nested vault are all accessible to the higher-level vault, including graph view, tags, etc, even those you create inside the nested vault.

I’ve tested notes with exactly the same name, one in the main vault and another in the nested vault, and everything worked fine. In the main vault, when I tried to link a text with the title of the notes inside the main vault, both appeared as suggestions, and if I chose the one in the nested vault, the [[title]] would be changed to [[folder\title]], so I needed to use the pipe. Besides that, everything works the same.

So, from what I gather, the only really hard rule of thumb is not to try to link, in any circumstance, to anything in another vault. But one question arises: is this even possible? I don’t think so: while you’re in the nested vault, you can’t even see what you have in the higher-level vaults, so how would you link to anything outside it?

One thing to be aware of, of course, is that if you create a tag in a nested vault, it will show up in the main one. If it is the same as another you have in the main, it will just show the note along with the other ones while you’re in the main vault.

2 Likes

not to try to link, in any circumstance, to anything in another vault. But one question arises: is this even possible?

Yes it is.
You can’t link to another vault while you are in a vault. But you can have a link made when you were in a higher vault; if you click to this it won’t be able to see the linked file and will offer to create it. That you don’t want.

Ah, I see. That is easily prevented by adding another tenet:

  • Don’t edit the notes of a nested vault from a higher-level vault. Only link to them from higher-level vaults and edit from the nested vault.

I think this would effectively prevent that error from happening. What do you think?

I use very few folders that aren’t in themselves vaults. I’m mostly flat.

I find this is perfectly easy with a flat system. Quick search for what you want to extract and there you are. Far more flexible than folders.

1 Like

Don’t edit the notes of a nested vault from a higher-level vault. Only link to them from higher-level vaults and edit from the nested vault.

All my files are in nested vaults and I have several tiers of nesting. I’m quite happy to make any links, any time, whichever vault I am in. If I have the same file open in two vaults at the same time, I may realise that a particular link can only be made in the higher one. I don’t hit problems because I know where the risks are and can deliberately skirt them. The main thing is understanding how it works.

For occasional or new users of nesting, it is a sensible rule to follow.

@Dor:
I use very few folders that aren’t in themselves vaults. I’m mostly flat.

I use as much folders as I feel I need at the top level, but haven’t found the need to go deep with folders within folders, as I can use MOCs or other types of meta-notes for that along with the other categorization methods (tags and others).

@Dor:
I find this is perfectly easy with a flat system. Quick search for what you want to extract and there you are. Far more flexible than folders.

Yes, but with folders, you don’t lose that option, either. You just have a pre-selection of related notes that you put there because they’re related somehow, even if that relation is not made explicit with tags, links between the folder notes or the note file names. That’s what I was aiming at with my point about folders, that it might be useful to incorporate in the vault in some cases, not that it is better than flat system or vice-versa. I believe they can coexist, and it seems now that you and I use a similar system regarding folders. I just wrote that because I’ve read people saying folders are useless.

@Dor:
All my files are in nested vaults and I have several tiers of nesting. I’m quite happy to make any links, any time, whichever vault I am in. If I have the same file open in two vaults at the same time, I may realise that a particular link can only be made in the higher one. I don’t hit problems because I know where the risks are and can deliberately skirt them. The main thing is understanding how it works.

I think this is the most difficult thing. I’ve been trying to replicate the error with a test-main vault and a test-1 nested vault (inside the main) but I’m still not sure how it is triggered. I believe it would be useful if we knew how to replicate that error consistently.

One thing I know: If I have two notes of the same name in the two vaults and the nested vault has a note with a link with that name, inside the nested vault it links to the note of the nested vault while on the main vault the link points to the note of the main vault, not the one originally linked to inside the nested vault, although it can also see it.

This means the links of the nested vault are effectively broken in the case the main vault has notes with exactly the same name.

I believe using the strategy of naming the notes “UID + Title” mitigates this problem. But then the point I made above about unlinked mentions becomes relevant.

If you’d have a moment to elaborate on some examples of use that triggers this error, please let me know.

I think I could reproduce errors consistently. It’s all about collisions - no collisions, no errors. If a link is shown doesn’t actually exist, then don’t click on it. if you don’t know the file genuinely doesn’t exist.

And keep your attachments where you expect to use them.

Folders definitely have uses and suit many people well. They are well supported by all operating systems. The problem they give is friction in in deciding where files go and, if you have many folders, they can also be a hindrance when looking for a file and the folder is remembered indistinctly.

I think I could reproduce errors consistently. It’s all about collisions - no collisions, no errors. If a link is shown doesn’t actually exist, then don’t click on it. if you don’t know the file genuinely doesn’t exist.

I agree, but I’m not sure if we’re on the same page regarding reproducing errors. Have you had an instance of any file being replaced by an empty note? I can’t seem to have this error happen. I’d like to know how to trigger this situation, or if it is possible.

The errors I’ve had so far are

  1. Error messages when a note in the nested vault points to a folder of the main vault (as obsidian doesn’t find the folder while in the nested vault);

  2. Breaking the correct link-chains between notes of the same name that exist in both vaults (e.g. note named “1” in nested vault points to note named “2” in the same vault, but if I click the same link while in the main vault I’m directed to note “1” of the main vault, if there is one, or it just creates one in the main vault, not actually replacing the original one in the nested vault. When I get back to the nested vault the link still points to “1” inside the nested vault).

That’s why I asked how you triggered errors that might have happened to you, to know if there is something I’m still unaware of and perhaps so the triggering scenarios can be explicitly told in a guide like your original post in this thread.

Folders definitely have uses and suit many people well. They are well supported by all operating systems. The problem they give is friction in in deciding where files go and, if you have many folders, they can also be a hindrance when looking for a file and the folder is remembered indistinctly.

I see your point and agree with you. In the end, it boils down to how each views each system of adjoining the notes and the meaning it has for them. There is no right or wrong. In my case, I always try to incorporate the various possibilities in contexts that benefit from them, and I see folders as a way to pre-select kinds of notes that I want together without having to explicitly make connections through tags, note name or links.

Only the link can be lost, not the file.
Set up a link in the top vault with a file outside the nested vault; click on that link from within the nested vault - it won’t see the file and will presume it has yet to be created, if you accept the offer, it will create a new file with the same name. You then have conflicting links depending on which vault you are in, which can be a problem if you are used to working on those files from both vaults.

I have never actually experienced any problem myself. One of the main issues, as pointed out in the @santi thread you referenced is that behaviour may change in the future because the integrity of the function is explicitly not protected. For now, with only a little care in use, it works perfectly well.

2 Likes