How db.md relates to other approaches

db.md is the open standard for databases in plain files: your data lives in files you can read, edit, and own, and a capable agent operates them directly. It is the database layer for the software agents make possible: personal apps, home-cooked tools, team workflows, agent-native products, and company systems.

The larger thesis is stack collapse. For a large class of semantic, evolving, workflow-heavy software, the old database/backend/frontend shape becomes readable context, an agent harness, and a generated surface. db.md is the persistence layer for that world: agent-operated files-as-database.

Most software that looks like an app is a database with a UI bolted on: tasks, trips, habits, customers, contracts, expenses, decisions, notes, and workflows wrapped around them. The old default was a database schema, migrations, and CRUD. db.md replaces both: the records become files, the agent is the query engine, and the surface is built on demand.

The question under every alternative is the same, asked on two axes: what sits between you and your data, and what each rides on as the models improve. With db.md nothing sits between, and what it rides on is the model itself. Most alternatives put a layer in the way, a server, a vendor, an engine, or a derived cache, and that layer is machinery you maintain, not intelligence rented from the model. Machinery gets better when someone does the work; the model gets better on its own, and db.md compounds with that curve.

Approach	What sits between you and your data	What it rides on
db.md	nothing: the data is the files; you read and edit them directly, and the agent works the same files	the model curve, directly: every new model works the same files better, with no vendor migration and no proprietary index to rebuild
SQL / relational databases	a schema you design up front and migrate when reality changes, a query language, and an app to use it	your schema and the app layer; a better model can write better SQL, but the store's meaning still lives outside the model
Airtable / Notion (the database with a UI)	a vendor's service you rent, your data on their servers; exports commonly lose live behavior, views, formulas, or relations	the vendor's roadmap; you get the AI they bolt on, when they ship it, and only inside their walls
Knowledge-graph memory	a derived graph beside your files, queried through an API, kept fresh only if the sync path stays correct	a better model too, but spent rebuilding a graph that can drift from your files, not working the files themselves
Vector RAG	a vector store of embeddings you cannot read or edit, reached only through a retrieval service	a separate retrieval stack: recall is bounded by embeddings, rerankers, and tuning you keep paying for
Karpathy's LLM Wiki	nothing: plain markdown the model reads (db.md's lineage)	the model curve, directly on the files (db.md's lineage)

Vector RAG is the approach db.md bets most directly against: db.md computes, stores, and searches no vector, ever. Where RAG engineers retrieval over embeddings of your data, db.md keeps the data as files and lets the frontier model read them, with semantic recall coming from the agent expanding the query over plain lexical search, not a separate embedding model.

The memory products built on that approach, by name, and what each stands for:

Memory tool	What it stands for	What sits between you and your data
Mem0	managed memory: an LLM extracts facts, embeds them, and retrieves by similarity; its 2026 migration adds ADD-only extraction, hybrid search, and entity linking	a vector-and-graph service you call; your memories are mediated by a retrieval stack
Letta / MemGPT	agent memory with editable memory blocks and archival retrieval	a runtime and retrieval layer around context; db.md keeps durable state as files
Zep / Graphiti	temporal memory built as a derived knowledge graph	a hosted graph and its API, a derived structure built from your data and kept in step with it
Cognee	an extract-and-load pipeline into graph and vector stores	one more derived store to build and keep in sync with your files
db.md	the data is the files; the agent is the query engine; no vector, ever	nothing: it rides the frontier model directly on the files you own

The mechanism is the whole argument. An embedding does not naturally tell you when a fact was true or whether it was later superseded; a dated file does. db.md answers time and knowledge-update questions by filtering frontmatter, not by hoping a vector lands nearby. The memory stack is already moving toward more explicit text and entity structure; db.md takes the endpoint seriously: dated files, frontier model, no vector tax.

Every tool here ships a memory system you adopt: a service, an engine, an index you rent and maintain. db.md ships a convention you own: plain files the frontier model reads and writes directly. The memory layer was always a database with the data hidden; db.md is the same job with the data left in the open.

For the genuinely hard remainder (high write concurrency, ACID, sub-millisecond reads, billions-row aggregates), a real database still backs db.md. That is the roadmap, not the claim for today.

db.md composes with the rest of the agent stack: AGENTS.md for instructions, MCP for tools. Different layers, not alternatives.

Your data belongs in files you own, not behind a server, a vendor, or a cache. The tool stays small and model-free; the intelligence is the agent's, rented not built. Most approaches ask you to maintain more machinery; db.md asks you to trust the model, and the model is the thing that compounds. db.md is the agent-native build-out of the LLM Wiki bet, replacing the database and the app over it for the broad class that was only ever records with a surface on top. Bet on the model, not the machinery.

What is db.md: the database claim, in full.
The db.md spec: the format definition.
Sizing and scale: how far plain files go, and where a packed engine still fits.
Repo: the Apache-2.0 source code.

How db.md relates to other approaches

Approach	What sits between you and your data	What it rides on
db.md	nothing: the data is the files; you read and edit them directly, and the agent works the same files	the model curve, directly: every new model works the same files better, with no vendor migration and no proprietary index to rebuild
SQL / relational databases	a schema you design up front and migrate when reality changes, a query language, and an app to use it	your schema and the app layer; a better model can write better SQL, but the store's meaning still lives outside the model
Airtable / Notion (the database with a UI)	a vendor's service you rent, your data on their servers; exports commonly lose live behavior, views, formulas, or relations	the vendor's roadmap; you get the AI they bolt on, when they ship it, and only inside their walls
Knowledge-graph memory	a derived graph beside your files, queried through an API, kept fresh only if the sync path stays correct	a better model too, but spent rebuilding a graph that can drift from your files, not working the files themselves
Vector RAG	a vector store of embeddings you cannot read or edit, reached only through a retrieval service	a separate retrieval stack: recall is bounded by embeddings, rerankers, and tuning you keep paying for
Karpathy's LLM Wiki	nothing: plain markdown the model reads (db.md's lineage)	the model curve, directly on the files (db.md's lineage)

The memory products built on that approach, by name, and what each stands for:

Memory tool	What it stands for	What sits between you and your data
Mem0	managed memory: an LLM extracts facts, embeds them, and retrieves by similarity; its 2026 migration adds ADD-only extraction, hybrid search, and entity linking	a vector-and-graph service you call; your memories are mediated by a retrieval stack
Letta / MemGPT	agent memory with editable memory blocks and archival retrieval	a runtime and retrieval layer around context; db.md keeps durable state as files
Zep / Graphiti	temporal memory built as a derived knowledge graph	a hosted graph and its API, a derived structure built from your data and kept in step with it
Cognee	an extract-and-load pipeline into graph and vector stores	one more derived store to build and keep in sync with your files
db.md	the data is the files; the agent is the query engine; no vector, ever	nothing: it rides the frontier model directly on the files you own

For the genuinely hard remainder (high write concurrency, ACID, sub-millisecond reads, billions-row aggregates), a real database still backs db.md. That is the roadmap, not the claim for today.

db.md composes with the rest of the agent stack: AGENTS.md for instructions, MCP for tools. Different layers, not alternatives.

How db.md relates to other approaches

Related

How db.md relates to other approaches

Related