AI StrategyMay 3, 20266 min read

Why I Switched From Notion to a Markdown Folder.

I used Notion for six years. Daily. Three thousand pages, twelve linked databases, a color-coded life. Last month I deleted my Notion workspace and moved everything into a folder…

JP

James Park

Head of Integrations

@@jamesparkdev
#local-first#notion#elyra#markdown#personal-ai

I used Notion for six years. Daily. Three thousand pages, twelve linked databases, a color-coded life. Last month I deleted my Notion workspace and moved everything into a folder of markdown files on my laptop.

This is not a tirade about Notion. Notion is a good product. The reason I switched is not that the product got worse. The reason is that the model of "your second brain in someone else's database" is the wrong model — and I did not realize it until I had to extract three thousand pages and discovered how much of "my" data was actually living as Notion-shaped relations I could not easily move.

Here is what the migration looked like, what I lost, and what I gained.

The Trigger

The trigger was simple. I wanted to plug an AI agent into my notes — not the Notion AI button, which is fine but cloud-coupled, but my own local agent that could read my goals, my reading list, my project briefs, and reason about my week.

Notion does not let you do this cleanly. The API is rate-limited. The block model is alien — paragraphs, lists, and headings are all separate API objects with parent-child relationships. Pulling a page out of Notion as plain markdown and feeding it to a local model required fighting the structure all the way down.

The frustration crystallized into a question: why is my data living in a structure that exists for Notion's convenience, not mine?

The Migration

I exported the workspace. The export is a folder of markdown files, organized by Notion's hierarchy. Each page becomes a .md file. Linked databases become tables in markdown. Embedded media becomes referenced files.

The export is imperfect. Toggle blocks survive. Synced blocks do not — they become duplicate paragraphs. Database views are lost; the underlying data survives but the saved filters are gone. Inline pages collapse to plain links.

I spent two weekends cleaning this up. I dropped about 20% of the content as obviously stale — old project plans, abandoned reading lists, a half-built tracker for a habit I had quit two years ago. The remaining 80% turned out to be roughly five hundred markdown files plus a few SQLite databases for the structured stuff.

That is the entire archive. Five hundred markdown files. About 12 megabytes total. I had been paying $10 a month to host 12 megabytes of plain text in a database I could not query.

What I Lost

I want to be honest about the trade-offs. The migration cost me real things.

Multiplayer collaboration. Notion is great for shared docs. I had a few pages I co-edited with my partner — household projects, a shared travel list. Those moved to a private Git repo with both of us as collaborators, which is not as smooth as Notion's real-time edit. We both adjusted; it is fine but not as polished.

Pretty rendering. Notion pages look nicer than markdown rendered in Obsidian or VS Code. The toggles, callouts, and embeds are well-designed. My local files look like markdown. I do not miss this as much as I expected, but I will not pretend the aesthetics are equivalent.

Cross-device search across the entire archive. I used to search Notion from my phone. Now my archive is on my laptop. I sync it via iCloud Drive, and I can read it on my phone, but the search is local-first and not as fast as Notion's index. For my use case this turned out to be fine — I almost never search the archive from my phone; I search it when I am working — but it is a real difference.

The forms. Notion's forms feature is genuinely useful for capturing structured input. I lost that. I replaced it with a shell alias that pipes into a markdown file with a date stamp. Less elegant. Same outcome.

These are real losses. They are not the kind of losses that justify keeping the entire archive in someone else's database.

What I Gained

The gains were larger than I expected.

Editor freedom. I edit in VS Code now. With my fingers. With the keyboard shortcuts I have built up over fifteen years. The Notion block model required a different muscle memory; the markdown text file does not.

Git as the audit log. Every change to my notes is a commit. I can git log a file and see exactly when I added that paragraph about the migration plan, when I edited it last, what the previous version said. This is the most useful journaling tool I have used. It exists for free.

The agent works. This was the entire point. Elyra reads my markdown files directly. The morning brief pulls from my goals.md, my reading list, and my running notes. The agent does not need an API. It needs a cat command. The integration that was complicated with Notion is trivial with a folder.

No rate limits. I can grep ten thousand files instantly. I cannot grep Notion at all. The performance difference is a category change.

Portability. If Elyra disappears tomorrow — ours, mine, the company's — my markdown folder still works. I open it in any editor. The agent might be gone. The data is not.

The Specific Problem That Notion Solves Less Well Each Year

Notion was designed when "personal knowledge management" meant manually linking pages, building relations, and curating a structure. The value proposition was the relational database for non-engineers.

In 2026, the value of manual relational structure is dropping. AI agents do the linking dynamically. They read your notes and find connections that are not in the schema. The careful relational structure I had built in Notion was, retrospectively, a workaround for the agent that did not exist when I built it.

When the agent does exist — and reads markdown directly — the database structure becomes overhead. You are paying with discipline (keep the schema clean!) for a benefit (semantic linking) that the agent now provides for free.

This is why the migration felt right and not nostalgic. The product I was using was solving a 2018 problem with a 2018 architecture. The 2026 problem is different.

The Workflow Now

My current workflow:

  • All notes in ~/notes/ as markdown files. Folders for: daily/, projects/, reading/, reference/, journal/.
  • VS Code as the editor. Obsidian when I want a visual graph view, which is rare.
  • iCloud Drive for cross-device sync. Imperfect, fine.
  • Git in a private repo for history.
  • Elyra reads ~/elyra/data/ (which is a subset of ~/notes/ plus the agent's generated briefs).

That is it. There are no apps to launch. There is no SaaS subscription. The whole thing is files.

What I Would Tell Someone Considering The Switch

Three honest things.

If you genuinely use Notion's relational databases for shared team workflows, do not switch. The team use case is the use case Notion is best at, and a markdown folder is not going to replace a project tracker for a five-person team.

If your Notion is mostly personal — your goals, your reading list, your weekly review, your project notes — switch. The day-one experience is rougher than Notion. The week-three experience is better. The year-three experience is dramatically better, because your archive is yours and your agent can read it.

The migration is the highest-friction part of the whole switch. Block a weekend. Accept that 20% of your old content was stale. Do not try to make the markdown look like Notion looked. The whole point is that it is text. Treat it like text.

Elyra reads markdown directly.

You Might Also Like