Why Obsidian and Markdown is the wrong approach for personal knowledge management

Obsidian is a wonderful tool, I love Obsidian and the philosophy.

But, I think it's fundamentally going to be the wrong approach for personal knowledge management, moving forward.

If you believe agents and AI are going to increasingly manage knowledge on your behalf, then you should be building systems for agents, not humans. Markdown is the wrong foundation.

What you need is a structured, relational database (like SQLite) as the direct backbone for your knowledge. You can use plugins and extensions, but they're duct tape.

I'm not 100% sure about this, but I'm pretty sure. This is my attempt to put some ideas out there and think this through. Roast me if you think i'm off.

I've made a video if you'd prefer to watch instead of read:

The File-First Philosophy

Steph Ango, CEO of Obsidian, has this "file over app" philosophy which I think is really elegant - basically, applications become obsolete but files persist, so your notes should be markdown files you control that are readable without any particular software.

File Over App - Steph Ango

Derek Sivers makes the same point — plain text is the most dependable and perennial format.

This is the sound reasoning behind all of us loving Obsidian.

But there's an implicit assumption here that you are the one reading these files, that you navigate them and you make the connections. What if that assumption is wrong?

Obsidian is Popping Off

Obsidian is popping off right now in certain pockets of the PKM universe because folks are plugging Claude Code into their knowledge base - reading, writing, organising their data. It feels like magic.

I posted in Nate B Jones' Substack community and almost all of the 50+ replies were from folks building their own custom Claude + Obsidian system.

Here's Balaji exploring a similar thread just yesterday.

So Claude Code is basically Claude with a specific bunch of tools, prompting and fine-tuning to make it really good at code generation - this is what they call the "harness". But here's the kicker - it turns out code completion extends beyond the IDE, it can manage your local knowledge base too.

The important part is that to make Claude good at working with code, it needs filesystem access and a bash tool, which allows it to do stuff outside the terminal - like manage Obsidian.

You basically have an intern who can understand goals, search the web, think, use your tools and control your computer. This is pretty fucking cool.

The Shift

We're heading somewhere weird with AI. You can debate the timeline, but you can't really debate the destination - agents are going to be steering more and more of the ship and you'll be delegating.

Anthropic made some pretty outrageous claims about how AI would change how engineers work and those predictions seemed crazy at the time, but now they don't seem so crazy.

METR Benchmark

There are lots of benchmarks to measure AI and most are kind of shitty because labs game them. METR is different because it tests how AI performs on real, difficult, longer tasks similar to what humans actually do.

If you give Opus a task that would take a human 5 hours, it completes that task without failing at least half the time. And the length of tasks AI can reliably complete has been growing exponentially, roughly doubling every 7 months.

So if agents can complete hours of work with increasing accuracy, you're going to have a swarm of agents working in and from your knowledge base, and there's going to be an increasing incentive to manage that knowledge via agents.

Frontend is Ephemeral

Even if you want to control your UI - right now there are countless tools like v0, Replit, Lovable - but they're also going to be short-lived.

If your knowledge base is well-organised, you can just tell Claude Code to build a UI for it. What doesn't change is the backend, the data structure, the schema - the backbone is the durable layer and the pixels are kind of ephemeral.

Your Options

So what are your options for storing knowledge in an agentic world? It's a game of tradeoffs.

Crudely speaking, three buckets:

1. Unstructured/semi-structured files — Obsidian
2. Relational databases — Postgres, SQLite (like Notion)
3. Graph/temporal graph — Neo4j, Graphiti, Zep (like Roam)

Notion runs on Postgres, Roam uses Datomic - but both are cloud, no bueno, you don't own your data.

Companies like Graphiti and Zep do incredible work with graph databases but that's enterprise-level infrastructure, probably overkill for personal stuff.

So for local personal knowledge management, you're really choosing between local files/folders (Obsidian, Logseq) or local SQLite which is a real database in a single file.

If you're doing very light note-taking, markdown and grep is probably fine. But if you're doing any kind of rigorous daily research, local SQLite is the sweet spot.

Why SQLite

SQL is the language you use to communicate with your database and SQLite is a database that lives in a single file - no servers, no setup, no background service.

Richard Hipp created it in 2000 for the US Navy because they needed a database that worked on battleships with no internet. It's now the most deployed database in history, it's on every phone, every browser, every Mac.

Two important things here: LLMs speak fluent SQL because it's everywhere in the training data, and structure enables indexing so it knows where to look and how to ask.

As a metaphor - Markdown is a pile of papers, SQLite is a filing cabinet with labeled tabs.

The Bolt-On Problem

The Obsidian community is great and there are many extensions to address limitations, but it's duct tape.

Reddit: Who else cannot wait to see databases natively in Obsidian?

Even Obsidian's new Bases feature is duct tape - it's just a query layer on top of markdown files and your data still lives in .md files.

From their own documentation: "It is critical to understand that, by design, Obsidian Bases do not read, parse, or query the main content of a note."

From one user: "There are tons of ways to use Dataview and tags/frontmatter as a query language to simulate a database... However, it can't replace using something like SQLite or DuckDB."

Another example is Logseq - they switched to SQLite but Reddit users who examined the source found it's just a single table, a key-value store. The whole thing loads into RAM at startup and SQLite is basically just the save file.

Reddit: Technical discussion before switching to Obsidian

As one user put it: "Using SQLite for a single table is almost laughable as no SQL JOINs are possible."

A properly designed relational schema with a nodes table, edges table, typed relationships - that's what makes something agent-native, not just the file format.

Context Graphs and First-Class Connections

There are people talking about 'context graphs' for enterprise, basically how old software models are dead.

Foundation Capital: Context Graphs - AI's Trillion Dollar Opportunity

Jaya Gupta explains this well - traditional software captures the what, not the why, and the opportunity is for agentic systems to capture the evolution of events rather than just the event itself.

She's talking about enterprise software but the same structural problem exists in personal knowledge management. Obsidian captures your notes as they exist now, not the thinking that produced them.

Animesh Koratana on the Two Clocks Problem

Animesh Koratana calls it the two clocks problem:

• State clock: what's true now
• Event clock: what happened, and why

We've built everything for state and almost nothing for reasoning.

What's Next

The excitement about Claude Code plus Obsidian is real and justified, it works today.

But I think it's built for the wrong end user.

We should be building our knowledge directly into queryable relational databases. I could be wrong, but it really makes no logical sense that this would be markdown - it's gotta be a properly designed relational database with explicit nodes, edges, and queryable structure. SQLite seems like the best bet for an agentic future and everything else is just an unnecessary abstraction.

Try It

If you're not sure about this, go and try it out.

Take your Obsidian vault, parse the markdown into a proper SQLite database with nodes and edges, spin up a frontend to work with a small slice of your data. Migration will be easier than you think and I did this myself - will keep sharing the process.

If you don't want to build it yourself, I've already built one. ra-h.app is a free Mac app with local SQLite, explicit nodes and edges, designed for agents.

And I'll keep sharing open source versions with the fundamentals so you can build your own if that's more your style.