Your filesystem is already a database. Most tools just don't treat it that way.
That's the core idea behind the Markdown Database Pattern — written up properly on The Way of Markdown, a site we've been contributing to that makes the case for building things on plain markdown instead of locked-in platforms. We think it's a pattern worth more attention, so here's the short version.
Treat a folder of markdown files as a database. Each file is a record. Frontmatter fields are columns. Directories are tables. Tags, wikilinks, and tasks in the body become queryable relations.
Filesystem Database
──────────────────────────────────
markdown file → record
frontmatter field → column
directory → table
#tag → tag relation
[[wikilink]] → link relation
- [ ] task → task relation
You get portability, version control (git works perfectly on plain text), no framework lock-in, and full queryability. You give up scale and real relational joins — this isn't for millions of records. It's a lightweight database, honest about its limits.
Once you name it, you start seeing it everywhere. Obsidian Bases and Dataview already do versions of this, half-consciously. A team wiki where every page has a status and owner field is one. A blog with date and tags in frontmatter is one — it just doesn't know it yet.
Sweet spot: up to roughly 10k files. Past that, reach for a real database. Below it, this gets you almost everything a database gives you, at a fraction of the complexity, with none of the lock-in.
The full writeup — the complete tradeoff analysis, a worked example with actual queries, how to implement it in a weekend, and the tool (MarkdownDB) that does it for you — is here: wayofmarkdown.com/markdown-database
Top comments (1)
This is a strong pattern because it recognizes an important engineering tradeoff: the filesystem can be the persistence layer when the dataset, concurrency model, and query requirements are constrained.
What I particularly like is the explicit boundary around scale. Treating Markdown as a database doesn't mean pretending it replaces PostgreSQL; it means choosing a simpler storage model when human readability, Git history, portability, and low operational overhead are more valuable than transactional guarantees and complex relational queries.
The interesting technical challenge is the layer above the files. Once frontmatter becomes your schema, you need to think about schema validation, indexing, stale indexes, concurrent writes, atomic updates, link integrity, and deterministic query semantics. Those details are what ultimately separate a convenient Markdown convention from a dependable Markdown database engine.
I could see this working especially well for internal knowledge systems, project metadata, documentation, lightweight CMSs, configuration-driven tooling, and small team workflows where humans need to inspect and edit the underlying records directly.
The 10k-file guideline is also useful as a practical constraint, although I'd treat it as workload-dependent rather than a universal threshold. A directory with 10k tiny files and simple metadata queries can behave very differently from 2k files containing expensive parsing, backlinks, or frequent concurrent writes.
Overall, I think the strongest argument isn't “Markdown is a database.” It's “use the filesystem as a database when your application's requirements naturally fit the filesystem.” That's a much more defensible and useful engineering principle.
I'd be interested in seeing where MarkdownDB goes next—particularly indexing, concurrency, schema evolution, and consistency as the dataset grows. Those are the areas where this pattern could become genuinely interesting for production tooling.