I've been comfortable on cloud platforms for years, but with how much online data is being absorbed for LLM training, I've been wondering how far I can get managing my data myself. Local-first computing has a genuine appeal: everything is a file, you own your data, no vendor lock-in, no shifting terms of service. My digital brain seemed like a good place to experiment, so after many years on Notion, I migrated to a local Obsidian setup.
I ultimately switched back. I expected to miss Notion's polish and collaboration features, and I did, but the deeper friction came from places I hadn't anticipated: the mismatch between iCloud and Unix tools, the hidden costs of "everything is a file," and the gap between what local-first promises and what it requires. The experience changed how I think about what "local" actually means.
Why bother
Several things drew me to the idea. Local files can be fed directly to language models, as there's no export step, and no API calls to retrieve my own data. My notes become easily discoverable by agentic tools like Claude Code. I also have a nostalgia for the Unix philosophy of "everything is a file," primarily for its composability. Files work with grep, with git, with shell scripts, with every tool built over the past fifty years.
There was also the ownership question. These are my most personal notes: ideas, reflections, half-formed plans, private thoughts. My instinct was to keep them under my own roof. And I liked the idea of colocation: project notes living in the same directory as code and datasets. If a meeting involves writing a quick script to analyze some data, why silo the notes elsewhere?
With these goals in mind, I migrated. Exported from Notion, imported into Obsidian, set up iCloud sync for cross-device access. The initial experience was positive. Obsidian's community and plugin ecosystem are impressive. I appreciated their development model enough to purchase a license. My local-first experiment seemed like a success: I had control, I had files, and my AI workflows were simpler. But after a few weeks, friction began to show.
iCloud and the command line
iCloud sync works beautifully until you touch files from the terminal. iCloud Drive is a synchronized database managed by background processes, and most command-line tools bypass the APIs it depends on. I wrote a separate post covering the technical details, but the practical consequence is that shell operations (rm, mv, git hooks, build scripts) can corrupt iCloud's sync state in ways that are difficult to diagnose and painful to fix.
For my use case, this was the most severe friction point. A primary reason for wanting local files was to embed notes alongside scripts and data, and scripts operate through the shell, not the Finder. The use case I'd optimized for directly conflicted with how iCloud expects files to be managed.
I eventually corrupted my sync database badly enough that the only fix was disconnecting and reconnecting my entire iCloud account. My drive is hundreds of gigabytes. Re-syncing took the better part of a day.
If you want to access your Obsidian vault from iOS, there's no real alternative to iCloud. Obsidian Sync exists as a separate paid service, but for Apple device users, iCloud is the path of least resistance, which makes its command-line incompatibility particularly frustrating.
The attachment problem
One friction point deserves more detail: how embedded files are managed.
In Notion, when you embed an image or PDF in a note, it just exists there. It's part of the note. You don't think about where the file lives. There is no "where." The attachment is intrinsic to the page, stored in Notion's infrastructure, and rendered inline. The mental model is simple: a note contains content, and that content can include files. You are operating a WYSIWYG interface that abstracts away the details of where and how embedded files are stored.
In Obsidian, an embedded file is a markdown link to a file that lives somewhere else. The syntax is clean (![[diagram.png]] or ) but the file needs a physical location in your file system. This is a necessary consequence of "everything is a file." If notes are files, and attachments are files, then attachments can't live inside notes. They live alongside notes, connected by references.
Obsidian offers several options for where attachments go. In Settings > Files & Links, you can choose: the vault root folder, a specific folder you designate, the same folder as the current note, or a subfolder relative to the current note. Each approach has trade-offs, and the Obsidian community has debated these at length.
I considered two reasonable configurations.
Option one: create a directory for each note. Inside the directory, a note.md file plus any attachments. When you embed an image in the note, the image lives right there with it. This preserves colocation, where the note and its files are a self-contained unit. You can export a note to another location and know all its dependencies come with it. But the cost is structural complexity. Every note now requires a folder. Your notes list becomes a list of folders, each containing a generically-named note.md. Navigation gets awkward. The hierarchy you're imposing doesn't reflect semantic organization, instead, it's purely mechanical scaffolding to keep attachments colocated.
Option two: keep notes in a flat structure with descriptive filenames (2025-12-01-My-Idea.md, 2025-12-02-Meeting.md) and put all attachments in a shared files/ or attachments/ subdirectory. This keeps notes browsable. The navigation sidebar shows actual note titles, not folder names.
But then, the attachments directory becomes a soup of disconnected files. image.png, diagram-v2.png, meeting-notes-scan.pdf, so hundreds of files with no obvious connection to their referencing notes. Which notes use image.png? Is old-screenshot.png still referenced by anything, or is it orphaned? There's no easy way to answer these questions without grepping through all your notes.
The problem gets worse when you move or reorganize notes. In Obsidian, if you move a note to a different folder, Obsidian updates the links in the note, but the attachments stay where they are. Your note now references files in a different directory, and the colocation you had is silently lost. Community plugins like Consistent Attachments and Links exist to help, and they can move attachments alongside notes and update links. But you need to know these plugins exist, install them, configure them, and trust them not to corrupt your vault. It's another piece of infrastructure you're responsible for.
Interestingly, even Steph Ango, Obsidian's CEO, uses a single central attachments folder for his personal vault. His reasoning: "I use very few folders. I avoid folders because many of my entries belong to more than one area of thought. My system is oriented towards speed and laziness." That's honest, and it works for him. But it also implicitly acknowledges that Obsidian's file-based model creates organizational complexity that users must actively manage.
The deeper issue is that "note with embedded content" is a different abstraction than "markdown file plus linked assets in a directory structure." The former is what I think about when taking notes. The latter is what the file system requires. Notion's cloud-based model means it can provide the first abstraction natively. Obsidian's file-based model means I have to build and maintain the machinery to approximate it.
Neither is wrong. But one requires ongoing cognitive overhead, and one doesn't.
Vault size
My idea of mixing data with notes created another problem: vault size. Once I got above 40GB, Obsidian started to choke on indexing. It has to scan the entire vault to build its link graph and search index. Launch times became unpredictable. Most of the space was occupied by large binary files not referenced by Obsidian notes (research files for data analysis), but they nevertheless seem to affect indexing.
Once indexed, everything worked fine. But sometimes I need to capture an idea quickly: on the subway, between meetings, walking between buildings. Those moments don't wait for loading spinners. A notes app that isn't instant defeats part of its purpose.
A side annoyance: on iOS, the vault must live in Obsidian's iCloud container, not in the project directory where I want it. The colocation that motivated the whole experiment is structurally impossible on mobile.
Collaboration and configuration
The collaboration gap was clearer-cut. Obsidian has no viable model for working with other people. No shared pages, no edit tracking, no access controls. Notion makes all of this trivial. If you need to collaborate (and I do, regularly) Obsidian is simply a non-starter.
Then there was the plugin treadmill. I found myself chasing Notion's UX feature by feature. Collapsible lists. Breathing room around bullet points. Emojis on pages and in navigation. Web link previews. "Mention" rendering that shows page titles inline. Each required finding a plugin, configuring it, sometimes troubleshooting compatibility issues.
Obsidian's plugin architecture is impressive, and I probably could have built the remaining gaps myself (and enjoyed the process), but I simply don't have the bandwidth to spend on that.
Coming back
After several months, I decided to migrate back. The friction had accumulated: this wasn't the right fit for my use case.
Migrating back proved its own challenge. Existing tools for Notion import didn't handle my needs: the folder hierarchy, the embedded files, the wiki-style links. So I built my own migration tool.
It walks a directory tree, creates nested Notion pages to preserve folder structure, and handles wiki-style links and embedded files. I open-sourced it at notion-markdown-importer in case it's useful to anyone making a similar move.
Back in Notion, the friction disappeared. Sync works across devices. Collaboration is first-class. Attachments live inside pages. And with MCP, connecting notes to LLMs is now straightforward, one of the original motivations for going local in the first place.
Notion isn't perfect. The offline experience is weaker. You're dependent on their service continuing to exist and remain affordable. The load times are still sometimes slow enough to disrupt my flow. The local-file advantages I originally sought (AI context, Unix composability) are real costs I'm accepting.
But I've come to think of "local" as hiding complexity rather than eliminating it. Local files still need to sync, and that syncing depends on infrastructure with its own failure modes. They need indexing for fast search, and that takes resources. The flexibility is real, but exercising it means building and maintaining the features you need. There's a reason WYSIWYG interfaces exist: a notes app works best when the underlying structure disappears and you're left with just your thinking. Markdown and file paths keep the machinery visible, a virtue when writing code, but friction when capturing a thought.
I like Obsidian's philosophy. I respect their development model. If the friction hadn't piled up, I'd still be there. What surprised me was how much of my preference came down not to which abstraction was better, but to where I wanted the inevitable complexity to live.