Why Claude Code + Obsidian Won't Replace RAG

« Claude Code + Obsidian replaces RAG. »

The phrase has been looping for weeks. On paper it looks great: a folder of linked Markdown notes, a knowledge graph that draws itself, ten minutes of setup. It feels like you just solved document search for good.

But this approach was designed for one specific use: a personal second brain. Not for indexing a company's documents, not for multiple users, not for production.

I tested the concept on a real business RAG use case. Here is what actually happens when you push it past the demo.

The test: technical manuals, a graph, one simple question

I gave Claude Code a dozen technical documents, the kind a boat-engine workshop uses daily: fault finding, possible diagnoses, equipment, parts, remedies. Set up the way I described in this article about deploying an LLM Wiki with Claude Code and Obsidian.

Claude Code generates its notes, creates the wiki links, and draws a graph. On screen it looks impressive. Clusters appear, entities connect, everything feels organized. That is exactly the moment you think this is a game changer.

Then comes a deliberately simple question: "My engine changes speed on its own. What is the diagnosis?"

Generated answer: air intake in the circuit, clogged fuel filter, carbonized exhaust manifold, dirty propeller. Plausible causes. But for this specific symptom, the manual says something else: when two engines desynchronize, the likely cause is a poorly adjusted or seized control cable, a push-pull cable travel that is too short, a faulty electric control. Push the system with a few hints and it eventually lists the right causes, but the remedies around synchronization stay absent from the answer.

The reference document for this case (page 132 of the manual) held all of it. The assistant looked at that document without retrieving what mattered. Result: a long answer, not false exactly, but off target. A partial hallucination on a use case where a technician needs the right procedure in seconds.

That is not a bug. It is structural. Three reasons.

Why context rots, and why it gets expensive

First: context size.

Classic RAG works like this. I take the question, embed it, which gives it coordinates in a space with thousands of dimensions, then search my vector database for the passages with the closest coordinates. I keep a few relevant chunks and feed only those to the LLM. Few tokens, so a precise answer and a query that costs a few cents.

Obsidian works backwards. The AI does not search nearby passages: it navigates the note structure, follows the relations, and pushes the whole chain into context to answer. On a small base, that works. But a base is alive, it grows every day (Web Clipper especially). The context window fills up on every query, and so does the bill.

LLMs rely on an attention mechanism. Past 30% of context-window usage, performance drops. The more context you add, the more the model forgets, especially the middle. That is context rot. As your base grows, every query costs more time and money.

Concrete math. A query that loads 200,000 tokens of context is roughly 2 to 3 EUR. Fifty queries per day in a team, and you are at roughly 3,000 EUR per month, every month. Plus the chaos: auto-generated entities contradict each other, everything becomes unreadable.

Same volume, one tenth of the cost. And a persistent memory that updates without re-ingesting everything.

The other blocker is the "local" part. Obsidian was built for personal use, not for teams, not for a product, not for production. Multi-user becomes a nightmare.

Knowledge graph and graph RAG are not the same thing

The word "graph" confuses everyone. A knowledge graph and a graph RAG are not the same piece.

A knowledge graph is manual navigation: entities, clusters, linked notes. I want to know what John likes, I follow the "likes" relation and land on apples, strawberries, football. Targeted, top-down exploration from an entity.

Graph RAG starts from content. It chunks the documents, then builds relations between chunks from an ontology and intentional entities. You ask a question, a chunk surfaces, and the system pulls every linked chunk, including semantically distant ones you need for completeness. Valuable when reasoning across multiple documents.

Obsidian does the opposite of graph RAG. It starts from the global graph, from an entity X, and navigates top-down through relations to bring notes back. Fine for a short factual question on a small base. For multi-document reasoning, it is the wrong tool in the wrong place.

The real problem: entities generated without business logic

Deeper still, there is the auto-generation of entities. That is where it falls apart.

The AI creates entities based on textual proximity, not business logic. Three typical failures:

1. Homonyms become distinct entities. "Apple" the fruit, "Apple" the company, maybe even a typo "Applle": three separate nodes. A question about how much Apple sold in 2024 surfaces apples in the results. The combinatorial explosion of wrong relations pollutes every search.

2. Relations are born from textual chance. A marketing report mentions "budget" and, in the same strategy list, a note "café podcast". The AI links budget to café podcast. Later, a query about beverages surfaces the café podcast, therefore the budget, therefore everything else. The LLM wrestles with growing noise and the context saturates.

3. No normalization. "ROI", "return on investment", "profitability": three entities for one concept. Instead of one node gathering every topic about profitability, you get fragmented relations. A profitability query misses documents indexed under "ROI", and the other way around.

At scale, you end up with a graph polluted by false positives. A well-built graph RAG adds 15 to 25% precision over classic RAG. Only on one condition: entities and relations must be intentional, grounded in an ontology, not invented by the model on the fly.

For most projects, the most reliable recipe remains a simple, deliberate data model. On a maintenance use case: the "symptom" entity, then "possible cause", "diagnostic to run", "solution", "equipment". Every chunk carries the right metadata, the page, the source document. The matrix is short, maintainable, and scales without degrading.

SQL, vector search, graph RAG: each to its own terrain

There is no single best architecture. There is the right architecture for the data you process.

• Structured data: SQL retrieval is unbeatable. A database of breakdowns stored in Airtable or Postgres gets queried, not embedded.
• SQL + vector hybrid: that is 80% of RAG in production, and it delivers the best precision. SQL filters the scope, vector search finds the nearby passages.
• Graph RAG: reserved for multi-document cases where semantically distant relations matter for completeness. Up to 15 to 25% more precision when built properly, noise everywhere when it is not.

FAQ: limitations of Claude Code + Obsidian

What are the main limitations of using Claude Code with Obsidian for document indexing?

The main limitations include context rot, where the performance drops as context fills up, leading to higher costs. Additionally, Obsidian is built for personal use, making it unsuitable for multi-user environments, which can create chaos in a team setting.

How does the cost of queries differ between Obsidian and classic RAG?

Using Obsidian can cost about 2 to 3 EUR per query when loading 200,000 tokens, leading to around 3,000 EUR per month for a team. In contrast, classic RAG only costs approximately 0.30 EUR per query, totaling about 300 EUR per month.

What is the difference between a knowledge graph and graph RAG?

A knowledge graph involves manual navigation of entities and clusters for targeted exploration, while graph RAG builds relations from content chunks, enabling comprehensive reasoning across documents. Obsidian's approach does not support this multi-document reasoning effectively.

A method that holds

Getting from demo to production follows an unglamorous path:

1. Data audit. Understand the business logic and the relations between entities before writing a line of pipeline.
2. Data model. Set the ontology, the concepts and their links, together with the business team.
3. Ingestion pipelines. Turn documents and documentation into a queryable base, usually vectorial.
4. Retrieval pipelines. Build the bridge from the question to the selected chunks.
5. Interface. Put the result behind a user experience that hides the mechanics.

Phases 2 and 3 are the most important. That is where everything is decided, and that is where demos collapse: not at query time, but at ingestion, when you decide what to keep, how to split it, and which relations to accept.

Obsidian remains an excellent tool for taking linked notes and turning them into a usable second brain. Indexing and querying a company's knowledge is a different game. Expertise is no longer in picking the model. It is in distributing the work between the base, the graph, and the LLM.

That is exactly what an Externalized AI Direction does: set a solid data model, build the ingestion pipelines, and ship an assistant that answers correctly in production, from 990 EUR excl. VAT/month.

Want to see what your data could become as a real business assistant? The Express AI Audit is free: 45 minutes, no commitment, just a concrete use case. Book it here.