Your Notes Can Be a Database Without a Silo
A database is only two things: structured data and a way to query it. Neither half has to live inside a proprietary app. The durable version of "my notes are a database" keeps the data as plain Markdown files you own, then bolts the query layer on afterward — so the records outlive whatever tool you query them with.
The phrasing is suddenly everywhere. In May 2025, Obsidian shipped a core plugin it described, in its own changelog, as one that "lets you turn any set of notes into a powerful database."1 The idea caught: a front-page Hacker News thread on the feature drew 695 points and 255 comments.2
But the excitement skips the question that decides whether you'll still have your data in a decade — not can my notes be a database, but what kind of database, and who holds the keys.
What people mean when they say "my notes are a database now"
The 2026 wave is real and worth taking seriously. People mean that the lists, projects, reading logs, and contacts they keep as notes can now be filtered, sorted, and viewed like rows in a table, all without leaving their note app. The capability is genuine. The framing is what needs a second look.
Obsidian's own description is precise about where the data lives: "All the data in a base is backed by your local Markdown files and properties stored in YAML."3 That single sentence is the whole argument of this essay, stated by the tool that started the wave. The "database" is a view. The substance is still files.
The structure that makes the view possible, the typed fields, already sits at the top of each note as YAML, what Obsidian calls properties: "Properties are stored in YAML format at the top of the file."4
So the breathless version — "my notes are a database now" — is true. It's just incomplete. A view is only as durable as the thing it reads.
The trap is welding the structure to the app
The danger is not structure. The danger is letting the structure live only inside one vendor's engine, so that the day you leave, the shape of your data leaves with it. A view rebuilds in seconds. Re-keying three years of records by hand does not.
You can read the cost in the export receipts, and the most honest receipt is the vendor's own. Notion, describing how its workspaces leave, says: "Full page databases will be exports as a CSV file, with Markdown files for each subpage."5 A relational workspace flattens to spreadsheets and loose pages. It adds, about a common block type: "Callout blocks will be exported as HTML, as there is no Markdown equivalent."5
None of that is an accusation. It is the platform telling you, in its help docs, that the rich structure was theirs, and what you get back is the residue. That is the difference between data you use in an app and data you own.
This is the deeper case for files over apps. As Steph Ango, who leads Obsidian, puts it: "Apps are ephemeral, but your files have a chance to last."6 The structure you spent years building deserves the same chance the prose does.
A database is structured data plus a query layer
Split the word "database" in half and the trap dissolves. A database is structured data plus a way to query it, and you can own the first half outright while keeping the second swappable. The data lives as Markdown with YAML frontmatter readable anywhere; the query layer is a tool you point at those files and replace at will.
This is the local-first, own-your-data principle applied to structure rather than to prose, and it is exactly how the open tooling already works. MarkdownDB, a library with 490 stars on GitHub, "parses your markdown files to extract structured data (frontmatter, tags etc) and builds a queryable index either in JSON files or a local database (SQLite, MySQL, or PostgreSQL)."7 The files are the source; the index is derived.
Simon Willison's markdown-to-sqlite is a "CLI tool for loading markdown files into a SQLite database. YAML embedded in the markdown files will be used to populate additional columns."8 The official Datasette documentation frames the point plainly: it is "useful if you want to keep structured data in text form in a GitHub repository and use that to build a SQLite database."9
Notice the direction of the arrow. The text is the truth; the database is built from it, not the other way round. As Javier Ramírez, who builds queryable graphs over Markdown, writes: "If you can query that graph, Markdown stops being just documents — it becomes structured data."10
None of this is new, which is the point
The strongest evidence that "files as a database" is durable is that it predates the trend by decades and keeps coming back. This is not a 2026 hack. It is a recurring answer to a recurring need, and the older tools still run.
GNU Recutils, a GNU project, is "a set of tools and libraries to access human-editable, plain text databases called recfiles."11 Human-editable. Plain text. A database. The convention that carries the structure — YAML frontmatter — is older and more widespread than any note app: the Jekyll static-site generator has used it for years, requiring that "any file that contains a YAML front matter block will be processed" and that "the front matter must be the first thing in the file."12
The 2026 cluster simply rediscovers it. A young tool, Matterbase, offers "a database-like table view on frontmatter and YAML records in Markdown notes."13 Different decade, same shape: typed records in text you can open anywhere.
Where a real database still wins — say it out loud
Honesty first: a folder of Markdown files is not Postgres, and pretending otherwise would cost you the moment your needs grow past a person's reach. Plain text trades raw database power for durability and ownership, and that trade is worth naming out loud before you make it. Know exactly what you are giving up.
A purpose-built relational engine wins, decisively, when you need:
- Multi-table joins at scale — querying across thousands of interrelated records, fast, is what SQL engines are for.
- Referential integrity enforced by the engine — the database refuses to let a record point at something that no longer exists.
- Concurrent, real-time collaboration — many people writing the same dataset at once, with conflicts resolved for you.
- Large datasets and complex aggregation — millions of rows, heavy analytics, indexed lookups.
If that is your workload, use the real thing. The plain-text approach is for the data a person authors and curates by hand — projects, reading lists, a CRM-of-one, finances in a text file — where the dataset is human-scale and the priority is that it still opens in twenty years.
For that data, structured + queryable + owned beats structured + queryable + trapped. Match the tool to the job, then keep a copy of the truth in text either way.
What to actually do tomorrow
You do not need to migrate anything, buy anything, or move your notes to start. The structure that makes your notes queryable is a habit, not a platform you sign into. Three moves get you there, and all three leave the underlying files readable in any plain text editor you choose.
- Put the structure in the file. Add a small YAML frontmatter block to the notes you want to treat as records:
status:,due:,rating:, whatever your fields are. That block is your schema, and it travels with the note. - Keep the query layer swappable. Use a base view, a CLI tool, or a script that reads your files; never one that owns them. If the tool vanishes, your records are untouched.
- Make the text the source of truth. When a tool offers to store the canonical copy in its cloud, decline. Build the index from the files, so the files always win.
A note app that stores plain Markdown on your own device, works offline, and needs no account already gives you the first move and the third by default: the headings, lists, and YAML you type are files you hold, not rows in someone's cloud. That is the entire foundation MNMNOTE (mnmnote.com) is built on. The query layer can come and go; the data stays yours.
Frequently Asked Questions
Can I use Markdown or plain text as a database?
Yes. A database is structured data plus a query layer, and Markdown supplies both halves with help. YAML frontmatter at the top of each file carries the typed structure;4 tools like MarkdownDB, markdown-to-sqlite, and GNU Recutils provide the query layer by building an index from your files.7811 The text stays the source of truth.
How do I keep structured data without Notion lock-in?
Keep the canonical data as plain Markdown with YAML that you own, and build any queryable index from those files rather than storing the truth in a vendor's cloud.9 The contrast is concrete: Notion's own docs say exporting a workspace turns "full page databases" into CSV files and converts callout blocks to HTML "as there is no Markdown equivalent."5
What is Obsidian Bases?
Obsidian Bases is a core plugin, shipped in May 2025, that the company's changelog says "lets you turn any set of notes into a powerful database."1 Crucially, "all the data in a base is backed by your local Markdown files and properties stored in YAML."3 The data underneath the database view can stay in files you own.
Isn't a plain-text database too weak to be useful?
For human-authored, human-scale records like projects, reading lists, a personal CRM, or finances, it is plenty, and it is far more durable. For multi-table joins at scale, engine-enforced referential integrity, or real-time multi-user writes, a purpose-built relational database genuinely wins. The honest rule: match the tool to the workload, and keep the canonical copy in text regardless.
Is "plain text as a database" a new idea?
No, and that is its best credential. GNU Recutils has offered "human-editable, plain text databases called recfiles" as a GNU project for years,11 and YAML frontmatter as a structured-data convention long predates note apps. The Jekyll generator has required it for years.12 The 2026 wave rediscovers a pattern that has already survived multiple tool generations.
What is the most hackable personal database?
The most hackable database is one whose rows are human-readable files. When each record is a Markdown note with YAML fields, you can edit it in any text editor, version it with ordinary tools, and point any number of query tools at it. Power comes from the layers you add; durability comes from the text you never lock away.
A database doesn't have to be a silo — it only became one because we let the structure live where we couldn't reach it. The records you can still open in 2046 will be the ones that were always, underneath the query layer, just files you own.
Footnotes
-
Obsidian, "Obsidian 1.9.0 Desktop (early access)," changelog, 2025-05-21. https://obsidian.md/changelog/2025-05-21-desktop-v1.9.0/ (accessed 2026-06-15). ↩ ↩2
-
"Obsidian Bases," Hacker News (item 44945532), 2025-08-18 — 695 points, 255 comments. https://news.ycombinator.com/item?id=44945532 (accessed 2026-06-15). ↩
-
Obsidian, "Obsidian 1.9.0 Desktop (early access)," changelog, 2025-05-21. https://obsidian.md/changelog/2025-05-21-desktop-v1.9.0/ (accessed 2026-06-15). ↩ ↩2
-
Obsidian Help, "Properties." https://obsidian.md/help/properties (accessed 2026-06-15). ↩ ↩2
-
Notion Help, "Export your content." https://www.notion.com/help/export-your-content (accessed 2026-06-15). ↩ ↩2 ↩3
-
Steph Ango, "File over app," stephango.com. https://stephango.com/file-over-app (accessed 2026-06-15). ↩
-
datopian, "MarkdownDB," GitHub README (490 stars, 2026-06-15). https://github.com/datopian/markdowndb (accessed 2026-06-15). ↩ ↩2
-
Simon Willison, "markdown-to-sqlite," GitHub README. https://github.com/simonw/markdown-to-sqlite (accessed 2026-06-15). ↩ ↩2
-
Datasette documentation, "Ecosystem." https://docs.datasette.io/en/0.31.1/ecosystem.html (accessed 2026-06-15). ↩ ↩2
-
Javier Ramírez, "Turning Markdown Files into a Queryable Knowledge Graph," dev.to. https://dev.to/javier_ramrez_e2b4bb54fb/turning-markdown-files-into-a-queryable-knowledge-graph-4aho (accessed 2026-06-15). ↩
-
GNU Recutils, official homepage, GNU project. https://www.gnu.org/software/recutils/ (accessed 2026-06-15). ↩ ↩2 ↩3
-
Jekyll documentation, "Front Matter." https://jekyllrb.com/docs/front-matter/ (accessed 2026-06-15). ↩ ↩2
-
rhsev, "Matterbase," GitHub. https://github.com/rhsev/matterbase (accessed 2026-06-15). ↩