Why Obsidian and Markdown is the Wrong Approach for Personal Knowledge Management

If agents are going to manage your knowledge, you should be building systems for agents, not humans. Markdown is the wrong foundation. SQLite is the better backbone.

Obsidian is a wonderful tool. I love Obsidian. I love the philosophy. But here's my spicy take: I don't think it's going to be the right approach moving forward for personal knowledge management.

If you believe that agents and AIs are going to be interacting with your knowledge base, and that you're going to be interfacing through AI to work with your knowledge, then you should be building a system for the agents — not for the human.

Markdown is not the right foundation. The better foundation — where people are going to trend — is structured relational databases. SQLite locally. This should be the direct backbone of your knowledge. Plugins and extensions are duct tape.

Roast me if you got a different take.

File Over App

Steph Ango is the CEO of Obsidian. Years ago he articulated the "file over app" philosophy. It is why we love Obsidian.

Obsidian has been popping off in certain pockets of the PKM universe lately. Particularly among the tech-forward, AI-native crowd.

It's popping off because people are starting to plug AI tools, namely Claude Code, into their Obsidian vault — reading, writing, and using it to organize and work with their knowledge base. Which is really fucking cool.

I posted in Nate B Jones' Substack community asking what tools people use for PKM with language models. 50+ replies — almost everybody using some version of Claude, mostly Claude Code, with Obsidian.

So Claude Code plus Obsidian is prevailing as the go-to choice for local knowledge management with AI. And I think it's the wrong approach. We'll trend in a different direction.

What Claude Code Actually Is

Claude Code 101 for people who don't know: it's Claude with specific prompting, tools, and fine-tuning optimized for code generation. People call this the "harness".

The more interesting insight here is that it's opened up a whole world of different use cases and applications. Because to make Claude Code good at code generation and code completion, it needs to have access to certain tools. It needs to have file system access. It needs to have the bash tool so it can run commands.

And this means you can do other stuff on your computer — like manage your Obsidian vault. All of your Obsidian files are local on your device, so you can plug Claude Code in and use it to do research, organize your data, organize your knowledge.

You have an intern who can understand your goals with increasing clarity and coherence. It can search the web. It can think. It can use your tools and control your computer. Really, bash and file system are all you need.

The Shift

This leads to a shift in how we interact with our knowledge bases. We're going to have agents completing longer tasks over longer periods of time.

You can debate the timeline, but you can't debate where this is going. These agents are going to be steering the ship.

Two examples that indicate this is moving quicker than most people think.

Boris on Claude Code

Boris is the creator of Claude Code. He shared how his work has changed as a software engineer at Anthropic:

"Every morning I wake up and I start a few agents to just like start my code for the day. And it's crazy because if you'd asked me like 6 months ago if this is how I would code, I would be like, 'No, are you crazy? Like, how can you code in this way?' But it actually works. Like this is here and it works and this is how I write a lot of my code now."

Honestly, Anthropic have made some borderline outrageous claims about how things are going to progress, and the predictions just seem more and more realistic, not so crazy anymore.

And although software engineering and programming is verifiable in many ways that other tasks aren't, most knowledge work is just downstream of what's happening in software development right now. We're going to see this shift toward people delegating tasks to agents.

The METR Benchmark

Benchmarks are shitty. Labs game them and they measure against short specific challenges. The reason that the METR benchmark is better is because it's testing how these systems perform on real longer tasks similar to what humans are actually doing.

This benchmark measures how long a real multi-step task takes AI to complete successfully compared with how long that same task would take a competent human.

Look at Opus 4.5. If you've got a task that takes a human 5 hours to do — any general task that a human would need to do on the computer — Claude Opus 4.5 can do the same task and complete it to 50% accuracy. Half the time it can do it without failing.

The important thing to note here is the trend. The length of tasks that AI systems can reliably complete is growing exponentially. It's doubling every 7 months or so.

So if you believe that agents will be able to do hours of autonomous work, then it seems logical that you're going to have a swarm of agents working for you non-stop in your knowledge base. There's going to be an increasing incentive for you to manage that knowledge through these agents rather than managing it directly yourself.

The Interface is Ephemeral

A lot of people are stuck on the UI, the interface. That's basically what Obsidian is, right? Obsidian is a UI or an interface that sits over your own local markdown files.

There are countless tools to spin up interfaces — V0, Replit, Lovable. These are all short-lived. We're at the point where you can tell Claude Code: here is my SQLite database, build me a front end — and it just does it.

So the interface becomes less important. It's ephemeral. The more important thing is the backend, the structure, the database.

Your Options

What are your options when it comes to storing your data? It's a game of trade-offs. Always a game of trade-offs. There are three crude buckets:

Relational databases — Postgres or SQLite (what I'm recommending)
Graph/temporal graph databases — Neo4j, Graphiti, Zep
Unstructured/semi-structured files — the Obsidian approach

The trade-offs get confusing. I'm saying the best approach is a relational database, but I'm also saying it needs to be relational and local.

Notion runs on Postgres. Relational, but they own the data. Not local. No bueno. Same with Roam Research — graph database, but cloud. They own the data.

There's interesting things going on with Graphiti and Zep. These folks are building for enterprise — setting up graph structures to map entities, extract information, and make connections.

But the happy medium for local personal knowledge management is SQLite. Single file, lives on your device, and you can map your own graph. Just have a nodes table and an edges table. If you want to take it to the next level, bolt on Neo4j.

What people are doing now is trying to take their Obsidian markdown files and bolt on top of that a graph. That's backwards. Start with SQLite.

Why SQLite

SQL is just the language you use to communicate with your database. Richard Hipp created SQLite in 2000. He was working for the Navy. They needed a database with no server, no internet, no setup. So he built this. It's just a single file.

At its most basic, SQLite is a database that lives in a single file. No servers, no setup, no background service. It's now the most deployed database anywhere.

Two things people are overlooking:

Language models speak fluent SQL. It's everywhere in the training data.
Structure enables indexing and querying. Lightning fast for models to interact with.

LLMs know the language, and the structure makes it efficient to work with that data. Grep and markdown files work, but it's not the best approach.

As a metaphor: SQLite is like a filing cabinet — structured, enforced structure by design. Markdown is like a pile of papers.

The Bolt-On Problem

One of the great things about Obsidian is the community. There are so many great extensions built on top of Obsidian. And I know that everything I've mentioned as a limitation can be abstracted away with an extension or a tool. There's MCP servers. People are doing amazing things.

It's duct tape. You're trying to do what SQLite would give you out of the box.

Some examples. Obsidian released Bases. People got excited because they thought it was a migration to a database structure, but it's not. It's just displaying your markdown files in a table-like structure. The team clarified: "This does not mean we're supporting SQLite."

Another example is Logseq. They moved to SQLite, but it's basically one table, which defeats the purpose of having interconnected tables where you can build your own graph.

Context Graphs

A lot of people are talking about context graphs for enterprise — basically how the old software model is dead. This directly relates here.

A big consideration is having a database that by design maps the connections between your ideas and your notes.

Jaya Gupta and Animesh Koratana talk about this — traditional software captures the what but not the why. Not the event level. The opportunity is for agentic systems to capture the evolution of events rather than just the event itself.

They're coming at this from an enterprise level — building software with agents that understand the whole customer journey. But the same structural challenge exists for personal knowledge management. There's just not enough people talking about it because there's no money in it.

Think about it: Obsidian captures your notes as they exist now. But it doesn't capture the evolution of your ideas. You can do this with SQLite.

Connections as First-Class Citizens

In simple terms, the connections are as important as the nodes themselves.

In markdown, you can create tags, you can create connections between ideas, but those connections live inside the actual note itself.

With a SQLite database, you can have a separate table that maps connections between nodes. Maybe you have a nodes table, a table for books, a table for networking opportunities, a table for ideas. You have a separate table that maps the connections between everything.

This is good for both you and your agents. The agents like the structure because it's more efficient for them to work with that kind of data design.

This is also good for your thinking. If you believe that thinking and knowledge requires abstraction and connecting ideas — how does this idea relate to that idea? How does this idea contrast with this other idea I had? How did I extract this idea from this book and how does it relate to this podcast I listened to?

This is what I'm interested in. This SQLite structure, this relational database — it enhances cognitive function. It enhances your thinking if you're treating your connections between ideas as first-class citizens.

That's the more subtle point here — this collaborative process between AI and human cognition.

Try It Yourself

We're at the point now where you can go to Claude Code and say: "Go look in my Obsidian, take a subset of my vault, build it into a SQLite database, and create me a front end so I can view that data."

That's a 2-hour job right now. Worth exploring how that feels.

I love having my files in Obsidian. It feels robust. But SQLite is the future.

Let me know if you have a different take. I'm going to continue sharing how to build this out yourself. I have an open-source version — if you want to try it out, let me know.