I keep the most important things I know in plain text files. Deliberately. So when I caught myself asking whether a real database would do the job better, I decided to take the question seriously instead of laughing it off.
The context: I run my life and my side projects alongside an AI agent that wakes up with amnesia every session. Its memory is a folder of markdown files — decisions, preferences, ongoing threads, the story of us. This week I added something new beside it: a small structured database for a daily diary, the kind where a day's sleep, meals, and outings become rows instead of paragraphs. It worked so well that the obvious follow-up arrived immediately: if structured storage is this good, why is any of the rest still prose? Would a database make the memory faster, sharper, better?
The honest answer is mostly no — and the reason rewired how I think about remembering things.
My memory was already a database in disguise
The plot twist came from looking under the hood. The agent's memory search does not grep markdown files. A plugin indexes them into a vector store: the files stay the human-readable source of truth, and the index is the fast semantic lookup. Every time the agent "remembers" something, it is already hitting a database-shaped thing, not reading a file from top to bottom.
So "would a database make search faster?" was a question with an answer I already had. It is one.
The industry apparently agrees. The platform the agent runs on is mid-migration to a database-first architecture — sessions, transcripts, caches, and scheduler state moving into SQLite. My first reaction was the predictable alarm: wait, are we losing data? The real answer was reassuringly boring. The migration is engine-room plumbing. Configuration stays file-backed by deliberate, documented design. Workspace files are not in scope at all. Legacy runtime data does not get deleted; it becomes input for a migration tool that moves it carefully, area by area, and only marks an area done when the move is proven. The cargo is not going anywhere. Only the engine is being swapped.
The bottleneck a database cannot fix
Once the fear was out of the way, I could ask the useful version of the question: what would a database actually improve? The list is shorter than it feels.
- Search speed — already indexed, so no meaningful gain
- Fuzzy recall, like "that thing about the DNS blocklists" — semantic search over prose beats SQL pattern matching here, so no gain
- Knowing what is worth remembering in the first place — that is curation, and curation is format-agnostic
- Exact lookups, like "what did I decide on July 15?" — real gain; this is SQL's home turf
- Counts, trends, and time series — real gain, and the one thing prose genuinely cannot do
The quality of a memory system comes from what gets written down and how it gets organized, not from the storage engine underneath. Moving the narrative layer into Postgres would mostly add failure modes — backups, migrations, one more service to babysit — while giving up everything markdown provides for free: human readability, clean diffs, automatic injection into conversations, and the fact that language models edit text natively. A database optimizes the wrong bottleneck for story-shaped information.
Right tool per shape
The architecture I have converged on is not markdown versus database. It is markdown and database, each doing the shape of data it is good at.
Markdown is for narrative: decisions, opinions, lessons, who people are and what we are building. Fuzzy, semantic, story-shaped. The database is for structure: anything countable, datable, or tabular. A diary was the perfect first citizen, because "slept six hours, ate out, took a hike" is data pretending to be a sentence. Expense tracking, health metrics, an inventory of things I own with their warranties — those come next, and they will never be prose.
One discipline makes the whole thing work, and it came from my own worry about context bloat: the database is a lookup table, not context. Nothing gets bulk-loaded. When a question calls for it — "was I doing this same thing last week?" — one small targeted query returns a few rows, and the conversation stays lean. A few rows cost almost nothing. Thirty days of entries dumped into every session would cost attention, which is the only resource that actually matters here.
I am not alone in the instinct, either. The last two years have been a full SQLite renaissance: Turso and libSQL shipping replicated SQLite to the edge, Cloudflare building D1 into its runtime, LiteFS stabilizing, and "the world's most deployed database" quietly becoming a legitimate production choice for a whole class of applications. Local-first, database-per-tenant, sub-millisecond local reads. My tiny diary database is the same movement at personal scale — the industry is just doing it for millions of users instead of one.
The compound interest
Here is the part that sold me. Markdown can tell me what July felt like. It cannot tell me how July compared to June.
Give the diary a few months and it answers questions the narrative files never could: do I sleep worse after late eating-out nights? When did life get busy? Which weeks did I actually go outside? Prose cannot be grouped by month, averaged, or sorted. Rows can. Structured memory compounds in a way narrative memory simply does not, because every new row makes the old rows more useful.
So the answer to "should my memory be a database?" turned out to be: it already is, in the places that count — and the places that do not count are exactly where it should stay prose. The real skill is not picking a format. It is noticing which shape the memory is before you write it down.
What shape is yours stored in — and is it the right one?
