Using the Filesystem as a Database with Claude Code

Reading Satoshi Nakajima’s weekly newsletter “Life is Beautiful” on April 7, 2026, I had to stop and put it down.

Someone was using Claude Code not for software development, but to manage the whole of their daily life. Task lists, contact info, daily notes — all stored in the filesystem, with Claude Code handling every read and write. Nakajima found this compelling enough to build a prototype called MulmoClaude.

I’ve been using Claude Code every day for months. Reading that piece, I realized the Obsidian Vault + Claude Code setup I’d been quietly building for half a year was already this “filesystem as database” approach — I just hadn’t named it that.

What “Filesystem as Database” Actually Means

Traditional application development stores data in databases: PostgreSQL, MySQL, Firebase. You design a schema, implement CRUD operations, build a UI. That stack is solid, but it carries real costs:

• Schema design required (data structure decided upfront)
• CRUD API implementation required (code for every read and write)
• UI required (an interface for humans to operate the data)

With a filesystem-as-database approach, none of that is needed. Claude Code reads and writes files in natural language.

Say “save this person’s contact info,” and a Markdown file appears in the right directory. Say “show me last week’s task progress,” and Claude Code reads the relevant files and summarizes them. Schema definitions, API implementation, UI — Claude Code absorbs all of it.

My Obsidian Vault Was Already Doing This

I run an Obsidian Vault with around 4,000 files. I’ve set that vault as Claude Code’s working directory and built automation through custom slash commands.

Here’s what that looks like in practice:

Automated Information Gathering

The /daily-digest command pulls PubMed papers and Tech/Biz RSS feeds every day. Claude Code reads the feeds, triages by importance, and writes each item as an Obsidian note. /digest-newsletter does the same for newsletters in Gmail.

Breaking that down:

1. Fetch data from external APIs (a fetch script)
2. Analyze and categorize the data (Claude Code’s judgment)
3. Save results to files (written as Markdown)

No database. No web app. The Markdown files are the data store; Obsidian’s interface is the viewer.

Memory System

Claude Code has a mechanism for writing memory files under ~/.claude/projects/. I use this actively — accumulating project status, feedback history, and external resource references as files.

Those memory files are loaded at the start of each conversation, so context like “that thing we discussed last week” carries forward automatically. This is functionality that used to require a dedicated CRM or project management tool.

Zettelkasten Workflow

I accumulate notes from books and YouTube videos as Literature Notes in the vault. The /youtube-note command takes a video URL, fetches the content, and generates a structured note automatically.

Links between notes are managed through Obsidian’s backlinks, and a knowledge network grows naturally. No database anywhere in this pipeline.

Where SaaS Becomes Unnecessary

In the same newsletter, Nakajima wrote: “If Claude Code is used this way, SaaS businesses have nowhere left to stand.”

I think he’s half right, and half overstating it.

Where SaaS becomes unnecessary: personal task management, notes, information organization, journals, study notes — in other words, managing data that only you use. The territory covered by tools like Notion, Evernote, Todoist, and Google Keep can, in significant part, be replaced by Claude Code + the filesystem.

In practice, I’ve stopped using several SaaS tools:

• RSS reader → replaced by /daily-digest
• Newsletter management app → replaced by /digest-newsletter
• Reading notes app → replaced by the Zettelkasten workflow

Where SaaS is still necessary: multi-person collaboration, real-time sync, permission management, large-scale data aggregation — these aren’t solvable with a filesystem alone. Services like Slack, GitHub, and Supabase provide value a filesystem setup simply can’t replicate.

MulmoClaude’s Approach

Nakajima’s MulmoClaude takes this “filesystem as database” idea one step further.

There’s an existing GUI chat app called MulmoChat, which previously sent requests to the OpenAI or Anthropic API, with browser localStorage as a temporary data store.

MulmoClaude routes those requests to local Claude Code instead. Because Claude Code can access the filesystem, data persistence happens naturally. A shared “GUI Chat Protocol” makes switching between the GUI and CLI transparent.

This is one answer to the question: what should an AI-native computer interface look like? Instead of designing a schema, the AI decides the file structure autonomously. Instead of writing CRUD APIs, you manipulate data in natural language.

Challenges I’ve Run Into

Six months of running this setup has also revealed its limits.

Search performance: Once you cross 4,000 files, grep and Obsidian’s built-in search alone are no longer enough to reliably surface the right information. There are moments when vector or semantic search would help.

Structural consistency: When Claude Code creates files, directory structure and frontmatter formatting can drift subtly over time. Templates and validation help, but enforcement is nowhere near as strict as an RDB schema constraint.

Context window limits: Claude Code can only load so many files at once. Operations that require a bird’s-eye view of the whole vault need workarounds — splitting the task across subagents, for instance.

These are technically solvable. Integration with a vector database (ChromaDB, for example) or extending file operations via an MCP server should address most of them.

Getting Started with a Filesystem DB

If this sounds worth trying, here’s a minimal setup:

1. Install Obsidian and create an empty vault
2. Set that vault as Claude Code’s working directory
3. Write in CLAUDE.md: “This vault is a Markdown-based knowledge management system”
4. In daily use, just tell Claude Code: “Note this down” or “Show me yesterday’s memo”

The key at the start is not to over-specify the structure. Watch the directory structure and filenames Claude Code creates naturally, then let your CLAUDE.md rules evolve from there. This emergent structure ends up being more flexible and truer to how you actually use data than any schema you’d design upfront.

Claude Code adoption is accelerating, and the paradigm of “letting AI manage your files” is becoming a real option not just for software developers, but for anyone who works with information.

Where in your daily information management are you still relying on databases or SaaS? For some of that, files and AI might be enough.