Skip to main content
smolbren works natively with Obsidian vaults because it understands [[wikilinks]] and YAML frontmatter — the two building blocks Obsidian uses to structure a knowledge graph. Every note’s type field becomes a graph node label, and every frontmatter key whose values contain wikilinks becomes a typed graph edge. No plugins, no exports, no syncing: smolbren reads your vault directly from disk.
1

Find your vault path

Obsidian shows the full path to your vault in Settings → About, under the vault name at the top of the left sidebar.Common vault locations:Copy the full absolute path — you’ll use it in the next step.
2

Register the vault

Run smolbren vault add with a short name for the vault and its path. Pass --default to make it the vault smolbren uses when no --vault flag is given:
smolbren writes the registration to ~/.smolbren/config.json. You can register multiple vaults and switch between them with --vault <name>.To see all registered vaults:
3

Build the index

Run smolbren index to scan the vault, parse frontmatter and body text, build the BM25 full-text index, resolve wikilink edges, and write the index data to ~/.smolbren/vaults/obsidian/.
Subsequent runs are incremental: smolbren compares content hashes and only re-processes changed files, so re-indexing a large vault after a few edits takes a fraction of a second.
4

Explore the ontology

After indexing, inspect what smolbren discovered about your vault’s structure.Node types — the unique values of the type frontmatter key across all notes:
Edge types — the frontmatter keys that contained wikilinks, and how many edges each produced:
These are the labels and relationship types you’ll use in Cypher queries. See Graph Queries for patterns.

​
Working with Obsidian frontmatter

Obsidian calls YAML frontmatter “Properties”. smolbren treats these properties as the schema of your knowledge graph:
  • The type key defines the node label for that note.
  • Any key whose value is a wikilink (or a list of wikilinks) becomes a relationship type, with the host note as the source and the linked note(s) as targets.
  • All other scalar values (status, created, url, etc.) are stored in the frontmatter object returned by smolbren get.
Here is a realistic blog-post note and what smolbren derives from it:
From this single note, smolbren creates: Notes with no type key are still indexed and searchable — they just don’t carry a node label and are only reachable via the catch-all Note label in Cypher.

​
Keeping the index fresh

Run smolbren index again after you make changes in Obsidian. Because indexing is incremental, only modified files are re-processed:
If you want to rebuild the entire index from scratch — for example after renaming many files — pass --full:
There is no background daemon. Run smolbren index whenever you want the index to reflect the current state of your vault. Many users add it as a shell alias or a short script that runs before any search or query session.
iCloud and Dropbox vaults — just use the full path, including any cloud-provider path segments. For example, an iCloud-synced Obsidian vault on macOS lives at ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault. Pass that path directly to smolbren vault add; smolbren reads files through the local filesystem layer and doesn’t need to know about the cloud sync.
The .obsidian/ directory inside your vault — which stores Obsidian’s own configuration JSON files — is automatically skipped during indexing. Only .md files outside that directory are parsed.