Agents need persistent, searchable memory across tasks, and filesystems have emerged as the dominant storage/access layer. Indeed, you may have read articles like Files Are All You Need, or seen the dominance of tools (particularly coding agents) that use filesystem storage.
In this article, we’ll compare the capabilities of a filesystem with that of a database to better understand their use for agent context memory.
Requirements for agent context memory
Agents need a read-write store to capture context and results: tool calls, inputs, intermediate results, and more. An agent’s context memory must be searchable, relatively low-latency, and persistent between tasks. Long-term storage of logs and results may also be required.
Consider a coding agent when tasked to implement a new feature: it scans your code base, reads files, comes up with a plan, potentially asking for user clarification. If the task succeeds, a record should be persisted: plan, rationale, diffs or PR links, tests and benchmarks, tool traces, and any user approvals. If it fails, capture errors, dead ends, and corrective guidance.
What are filesystems good at?
Filesystems have great sequential read/write throughput and are easily searchable using tools like grep or by globbing directory structures. These sort of tools are readily accessible by agents.
These properties make filesystems well suited to append-only logs, single-user scratchpads, and for storing binary data (think artifact blobs).
Filesystems are also ubiquitous, simple, and portable. If you’re running an app, there’s a very low overhead to mounting a local filesystem.
When might you want to use a database instead?
Use a database when you need database features that a filesystem simply doesn’t support.
- Structured data: Access typed, normalized (dedupliciated) data that may be related to other data with primary/foreign keys.
- Rich Querying: grep/glob don’t scale to semantic filtering like vector similarity. In Oracle, complementary tools like Oracle Text or JSON Full-Text Search enhance SQL queries for text analysis and retrieval (including hybrid text/vector retrieval).
- Scalability: Indexing, clustering, caching, and failover are handled by the database layer. If you run cross-region, multi-replica, these features become critical.
- Concurrency: Databases easily handle writes from multiple, simultaneous users. While you can achieve this with a filesystem, it requires application-level locking and coordination.
- Security: Fine-grained, multi-tenant RBAC as well as auditing and governance that’s critical for multi-user agents and regulated data.
- Transactions: Access and mutate your data with ACID guarantees that span services,
Of course, databases come with additional overhead: a separate service requires independent management, and may introduce latency compared to a filesystem (network filesystems or block storage are likely to have similar latency).
Would you build a stateful app without a database? For me, the answer is no. Any stateful app I’ve developed has always used some kind of database/datastore; whether Oracle, Postgres, Redis, Kafka, Object Storage, or otherwise. Building a stateful app using only a filesystem runs the risk of reinventing the database. This is a large and complex task that should be avoided – unless that’s your goal!
Summary
The classic wisdom of when to use a filesystem or a database prevails. If your application (or agent, which is just a different type of app) has simple access patterns and storage requirements, a filesystem can work just fine.
There are certain things databases do extremely well. If you have many concurrent users, structured data, transactional requirements, or require indexing performance for large amounts of data – databases simply scale better. If you’re struggling with the limitations of filesystem context memory, don’t try to re-invent the database; just use existing, proven software.
Consider the complexity of your solution, how it will scale, and its overall requirements. Performing this analysis will help determine whether a filesystem or a database is better suited to your agent’s context memory.
A simple decision framework for filesystem vs. database vs. hybrid
- Choose a filesystem when you have single-agent or per-session scratchpad, large intermediate artifacts, and offline/local workflows.
- Choose a database when you have multi-agent sharing, retrieval at scale, robust governance/audit needs, and fine-grained policies.
- Choose a hybrid model when you need both small sandboxes and powerful, full-featured retrieval for curated memory. You may also consider Object storage as a powerful, scalable, distributed option that complements both.
Still not sure/can’t decide? Consider abstracting your memory API to make switching between filesystems and databases easier. Start simple, but design for evolution: filesystem for artifacts and local iteration, database for shared, governed, queryable memory, and a hybrid model for agents that need both.
References
- “Filesystem vs Database” by Leonie
- How agents can use filesystems for context engineering (LangChain Blog)
- Files Are All You Need (Llamaindex)
- Benchmarking Agent Memory (Letta)
Leave a Reply