How Much Memory Does Your Agent Need? — A Practical Memory Store Selection Guide

The Pain : You search GitHub and find everyone using different memory stores — ChromaDB, PostgreSQL, plain Markdown files, "SQLite is good enough for a decade." Which is right? The Answer : All of them. And none of them. Choosing without understanding your scenario is like buying a car without checking the road. 1. The Counter-Intuitive Question: Does Your Agent Actually Need "Memory"? When I was building a university admissions data scraper (91 universities), I made the classic mistake: I equipped the agent with a full ChromaDB + vector retrieval stack, spent three days tuning it, and then discovered — 95% of the agent's time was just reading "which page did I get to last time." A boolean would have sufficed. I built a vector database capable of semantic search. An engineer friend at ByteDance told me their internal agent platform found, after six months, that vector retrieval accounted for only 3.7% of all Memory Store requests. The remaining 96.3%? Key-value lookups, state reads/writes, error dedup. The vector search you spent two weeks integrating might serve less than 4% of your queries. So before discussing "which storage," we must answer a more fundamental question: what does your agent actually need to remember? I categorize memory into four types: Memory Type Typical Content Size Access Frequency Consistency Session state "Processing university 37/91" ~100 bytes Every call Strong Domain knowledge "A-University rate limit is 10 req/s" ~1KB On demand Eventual Error history "B-University returns 403 because UA blocked" ~MB Before new task Append-only Semantic memory "Map 'that red button' to settings page" varies Occasional Eventual See the pattern? If your agent mainly does multi-step automation (data scraping, report generation, CI/CD pipelines), the first three types are the real needs — and none of them require a vector database. Core thesis: memory selection is about finding the layer that is "just enough." One layer too many is waste; one layer too few i