I've moved my notes through four apps over the last decade: Google Keep, Evernote, Confluence, and Notion. Each migration was the same painful exercise: export to whatever lowest-common-denominator format the app deigned to offer, lose all my backlinks, lose all my embedded files, lose half my structure, and start over. Obsidian is the first note-taking app I trust to outlast itself, and it is not because of any feature. It is because of one decision: every note is a Markdown file in a folder on my disk. If Obsidian disappears tomorrow, my notes do not.
Plain text is the feature
Most note apps treat their database as the product. Open the .sqlite file or the proprietary blob and you find rows or JSON, parseable in principle but in practice opaque. Obsidian inverts this. Every note is a .md file with optional YAML frontmatter. Attachments live next to the notes as ordinary images and PDFs. The folder structure is whatever you want it to be, and the app is one of many ways to look at it. Git works on the vault out of the box. ripgrep works on the vault out of the box. Any text editor on earth can open any note. If I want to bulk-edit fifty notes with a sed command, I can.
Vault structure: notebooks, not folders
The shape of the vault matters as much as the format. After a few years of treating Obsidian as a flat pile of notes leaning on backlinks and search, I rebuilt the structure as a PARA-variant — Projects, Areas, Resources, Archives — extended with Zettelkasten note types and a few supporting folders. The visual treatment came from CyanVoxel's "Form, Function, & Fun" vault tour: each top-level folder is a visually distinct notebook with its own color in the sidebar, so the act of switching contexts feels like opening a different book instead of scrolling further down the same list.
The current shape, with personal note titles filed off:
Vault/
├─ 00 - Maps Of Contents/ — MOC index notes per major topic
├─ 01 - Projects/ — active projects with a defined done-state
├─ 02 - Areas/ — ongoing domains (no end date)
├─ 03 - Resources/ — external content captured and reviewed
├─ 04 - Permanent/ — evergreen reference notes, dashboard
├─ 05 - Fleeting/ — quick-capture inbox, triaged later
├─ 06 - Periodic/ — daily / weekly / monthly / yearly notes
├─ 07 - Archives/ — completed projects, retired content
├─ 08 - Databases/ — structured tables: Apps, Devices, Routines
├─ 09 - Agents/ — Claude coordination: plans, analyses, logs
├─ 70 - Links/ — link notes for external URLs and resources
├─ 80 - Tags/ — tag index notes, managed by metadata-menu
├─ 90 - Partials/ — reusable snippets embedded via [[transclusion]]
└─ 99 - Meta/ — templates, classes, scripts, trackerNumeric prefixes are a small but load-bearing trick: they force the file tree to sort by intent rather than alphabetically. The first ten slots (`00`–`09`) hold the active content; the `70`/`80`/`90`/`99` block sinks plumbing to the bottom of the tree where it stays out of the way. Each numbered folder is a notebook in the visual sense too — CyanVoxel's Colored-Sidebar CSS snippet tints each top-level folder in the file tree with its own accent, so I can tell which notebook I am inside at a glance.
The PARA-plus-Zettelkasten split is what keeps the structure from collapsing under its own weight. `01 - Projects/` and `02 - Areas/` follow Tiago Forte's PARA cleanly: projects are bounded with a done-state, areas are open-ended. `04 - Permanent/` and `05 - Fleeting/` come from the Zettelkasten side: a fleeting note is a half-formed thought that lives in the inbox until it gets promoted to a permanent reference note or thrown away. `06 - Periodic/` holds dated notes (daily and up); `00 - Maps Of Contents/` is where I keep the manually-curated indexes that knit the rest together.
`09 - Agents/` is the unusual one. It is a coordination layer for Claude Code — plans, analyses, session logs, agent state — so that long-running work the agent does has a durable home that lives alongside the rest of the vault and gets backed up the same way. The whole vault is a git repo with the obsidian-git plugin auto-committing changes, which makes "the agent edited my vault" no scarier than "I edited my vault."
Two patterns hold the structure together at the per-note level. The first is the folder-note pattern (via the folder-notes plugin): every folder has a note with the same name as the folder, and that note is the folder's index. Open the folder, the index renders a `folder-overview` block listing its contents. The second is consistent frontmatter — every note has `type`, `status`, `created-at`, `tags`, and a `parent:` link — which lets Dataview queries treat the vault as a small typed database and lets the Breadcrumbs plugin walk the parent chain to render breadcrumb navigation at the top of every note.
Daily notes, briefly
The single habit that turned Obsidian from a tool I owned into a tool I used was the daily-note template. Every morning, a new note appears in `06 - Periodic/`, and it becomes the anchor for everything else: every backlink to a project, a person, an idea threads through that day's note, so the daily log doubles as a chronological index of when each thing came up. The full daily / weekly / monthly / yearly rhythm — what each one is good for, how the templates differ, how they interlock — is a post of its own, coming separately.
Linking heuristics that survive
The temptation with a linked-note tool is to over-link. Every mention of every concept becomes a wiki-link, the graph view fills with hairballs, and after six months you stop trusting the links because half of them go to two-line stub notes. The heuristics that worked for me:
- Link a name the first time it appears in a note. After that, just type the name. The first link is what makes the backlink panel useful; the rest is noise.
- Don't create a note for something the moment you link to it. Let the link sit broken until the target genuinely deserves a page. Most stub notes never grow up; let them stay aspirational.
- Tags are for categorical metadata you might filter on later (#book, #person, #recipe). Links are for entities. Don't substitute one for the other.
- If a note is over 800 words and has no inbound links, it is probably a dead end. Either link to it from somewhere relevant or accept that it is an island.
- Aliases (in YAML) are how you handle synonyms. A person's note can have aliases for nicknames; a concept note can have aliases for British spellings. The link target stays canonical.
Dataview, used sparingly
Dataview is a community plugin that turns the vault into a small queryable database. You can write a query that lists every note tagged #book, sorted by date added, showing the author and rating columns from each note's frontmatter. The trap is that dashboards atrophy. You build a "currently reading" widget, you do not update it, the dashboard becomes a graveyard, and now you have a graveyard at the top of your daily note.
A query that has actually earned its keep in my vault is the running list of every open question I have ever written. Each daily note has a section where I jot things I do not understand yet; each line gets tagged #question. The Dataview block on my "Open Questions" note pulls all of them:
TABLE WITHOUT ID file.link AS "Note", created
FROM #question
WHERE !completed
SORT created DESCNo dashboard. Just a flat list of every unresolved question, with a backlink to the daily note where I asked it. About once a month I scroll through and answer or delete a few. The view stays useful because it is automatic. The moment a query needs maintenance to stay accurate, I delete it.
Sync and history
The vault is a git repository. The obsidian-git plugin auto-commits and auto-pushes on a schedule, which makes the version-control story invisible most of the time and indispensable the moment something goes wrong. Every save eventually becomes a commit. Every commit eventually lands on a private remote. If I delete a note by accident, git restores it. If a plugin corrupts a file, git shows me the diff. If I switch machines, I clone.
The reason I lean on git over a dedicated sync service is the same reason I lean on plain text and the notebook structure: the fewer pieces of the stack that require a specific vendor, the more durable the system. If Obsidian Sync vanished tomorrow, I would not lose data, but I would have to migrate. Git has not been vendor-locked in twenty years. If the CSS snippets stopped being maintained tomorrow, I would lose the colors but keep every note and every commit.
Where to crib the setup
The visual side of the vault is not my invention; I borrowed the bones from CyanVoxel's vault and adapted the structure. If you want to start from the same foundation, these are the resources I leaned on:
- CyanVoxel — "Form, Function, & Fun! - My Obsidian Vault Tour [2024]" and the surrounding playlist — https://www.youtube.com/watch?v=rAkerV8rlow&list=PLGPRU440sSI2uqW5YBeZSghhGTr1kts8o
- Obsidian-Colored-Sidebar (per-folder accent colors in the file tree) — https://github.com/CyanVoxel/Obsidian-Colored-Sidebar
- Obsidian-Daily-Themes (CSS treatment for daily notes) — https://github.com/CyanVoxel/Obsidian-Daily-Themes
Drop the snippets into `.obsidian/snippets/`, enable them in Appearance settings, and the file tree picks up its colors immediately. The vault structure is yours to design — the only suggestions I would defend are the numeric-prefix sort trick, a fleeting-inbox-plus-archive pair to absorb the things that do not yet belong anywhere, and the folder-note pattern as a way to give every top-level folder an index that does more than just exist.
The graph view is the screenshot every Obsidian post leads with. The backlinks panel is what actually does the work.