Databases are far from dead. Hot take within the vibe-coding community, but you can't build a reliable agentic memory system using files alone. The filesystem is a great interface for agents, but for complex, distributed, production applications, databases win hands down. I recorded a video to show you the... benchmarks. Large Language Models know how to navigate and work with the filesystem, but as soon as you add complexity, files will fall short. You need databases whenever any of the following happens: 1. You have concurrent writes from multiple agents or users 2. You need semantic retrieval at scale 3. You need ACID guarantees for shared state 4. You need audit trails and row-level access control 5. You need indexed queries over growing memory In the attached video, I'm running a notebook comparing a filesystem-backed agent with a database-backed agent. The three most important findings: • Filesystem = Database with small corpus, keyword-friendly queries • Databases > Filesystem with large corpus, fuzzy queries • Databases > Filesystem with concurrent writes without locking Numbers don't lie. You can run the benchmarks yourself.show more

Here is the funny part: I've seen several teams already putting a ton of time "hardening" their filesystem implementation to support concurrency and improve search results. Congratulations. You are just rebuilding a database! Conclusions: • Use files when building prototypes or single-user agents • Use databases for multi-user, multi-agent production apps. Here is the link to the notebook with the benchmarks: I'm flying next week to meet with the @OracleDevs team. We are talking about agent harnesses, memory, and how Oracle fits into that space. I'll report back!

Idk who are these people who think database are there to be replaced

not wrong about the technical side. but the vibe coders who are actually breaking things don't know what ACID means, don't know what indexed queries are, and definitely don't know they need a database. they just know their app "worked" and now it doesn't. i talk to these people daily.

100%. Files work great for single-agent local workflows. But the moment you're coordinating multiple agents with shared state and concurrent writes, you need ACID guarantees. A vector DB + relational store is basically the new memory stack for agent-native apps.

Is the real constraint the database, or the lack of schema discipline in how agents actually write state? Curious what failure modes you're seeing most.

file-as-state breaks first on concurrent writes. paperclip lost 3 days last month to a silent decisions.md merge - two agents wrote overlapping sections, last-writer-won, the dropped call surfaced a week later as 'wait why did we do X'. moved shared state to postgres, kept markdown as derived view. files = render layer, db = truth layer

The importance of this post cannot be overstated. This is exactly where I see so many people developing locally with AI, where it works great, until it's pushed into a production cloud environment and all hell breaks loose.

Agreed, since this is one of PINA engineering points that saves you pain later. If agent memory needs concurrency, fuzzy retrieval, permissions, or history, a database stops being old-school and starts being the thing keeping your product from eating itself.

A lot of vibe coding culture treats plain files like they magically replace decades of database engineering

This mirrors what I've seen building production RAG systems. Vector stores get all the attention, but real complexity is in the orchestration layer — knowing when to hit a relational DB vs vector index vs graph store. Files-for-everything is vibe coding waiting to collapse.

I did the actual math and it lost. Just saying

Counterpoint from production: we run agent memory on flat markdown files with git commits. Agents are stateless between runs, reload context each heartbeat. Append-and-read pattern, git handles history. Database would be overkill. Concurrent writes are where it breaks though.

this matches what i kept hitting on agent memory work. files give you the illusion of state, but the moment you need to query across runs or do anything resembling a join, you're rebuilding sqlite badly. the discipline of a real schema is the unlock.

I like files because they are legible, local, and easy to diff. I do not confuse them with memory. Once state becomes concurrent, relational, and query-heavy, the filesystem is the interface, not the substrate.

I have a system like you described called Reflex. I have an early version running, this next version will be more wide ranging.

The git-commits approach is underrated for single-agent setups, but you're hitting the right failure mode — concurrent writes. We went through the same evolution. The fix we landed on: stateless agents + a proper job queue (we use Postgres with SKIP LOCKED). Agents claim work, not files. File system stays an output layer, not a coordination layer.

Ran into this last quarter... started with files, six weeks later we had custom locking logic, a search index, and a retention script

the fact that "databases are actually useful for storing data" is currently considered a controversial hot take in the vibe-coding community tells you absolutely everything you need to know about the state of software engineering in 2026.

this. tried files-only for sovra's render queue early on — worked fine until 3 users hit the same job slot and we had no transactional guarantee. switched to postgres advisory locks next day. anyone running pure-files at scale and not hitting this?

This is exactly why I keep files as the output/render layer (nice markdown logs humans can read) but moved the actual agent state and semantic memory into Postgres with proper row-level security. Agents write to the DB first, then we derive the files. Zero merge conflicts, full audit trail, and the LLM still “sees” familiar text when it needs to. Databases don’t kill the filesystem they complement it.

yeah i've been thinking this; there's a current romance with markdown files doesn't mean we should be ignoring the powers available in many excellent databases

currently building open source concept on structured storage for skills basically it can add to most of the skills some additional “deep” level as different agents can effectively collaborate on some work

To run a multi-agent swarm, I had to move orchestration entirely to a DBOS (Database-Oriented OS). By keeping all agent state, queues, and semantic memory (via PG-Git) natively inside Postgres, the swarm gets full ACID compliance and lock-free concurrent execution. Files are for local configs; databases are for agents.

It's fine for some things. But if you overdo it, it becomes a problem. It will make the filesystem-as-database crowd rediscover transactions, indexes, and constraints one painful bug at a time.