Building a memory API without a vector database

AgentRAM started from a small frustration: giving an AI agent memory felt heavier than the problem deserved. Here is why I built a memory API without a vector database, what I used instead, and what I learned shipping it on my own from Accra.

The frustration that started it

I kept running into the same wall while building agents. The moment I wanted one to remember something between sessions, every path forward pointed at the same stack: pick a vector database, choose an embedding model, write the pipeline that turns text into vectors, then tune retrieval until it behaves. It was a lot of moving parts for what I actually needed, which was usually to store a value and read it back later.

The more I looked, the more it seemed like the whole category assumed you wanted semantic search. Sometimes you do. But a large share of agent memory is not search at all. It is remembering a preference, holding a piece of state, or passing a result between steps. None of that needs embeddings. It needs a place to put a value under a key.

The idea

So the idea was deliberately small. A memory API where one call stores a memory and another retrieves it, scoped by agent, with the option for several agents to share a pool. No vector database to run, no embedding pipeline to maintain, no infrastructure to babysit. If you can name the thing you are storing, you should be able to use it in a minute.

I wanted the simple case to be genuinely simple, not the simple case wrapped in a platform.

Why not just use Redis or Postgres?

This was the first honest question I had to answer, because a key-value store is not a new invention. The answer is that Redis and Postgres are building blocks, not a product an agent developer can point at and use immediately. To use them you still have to host them, secure them, manage connections, design the schema, and handle scaling. That is infrastructure work that has nothing to do with building your agent.

AgentRAM's job is to remove that work. It is the managed layer on top, with the agent-specific pieces already decided: memories are scoped by agent, namespaces can be shared, entries can expire on a schedule, and every operation is a single authenticated HTTP request. You get the usefulness of a key-value store without standing anything up.

The stack

I kept the stack boring on purpose, because boring is what ships and stays up.

• A plain REST API over HTTP, so it works with any language or agent framework that can make a request.
• Postgres for storage, through a managed provider, so I was not running a database server myself.
• Credit-based metering, where each store or retrieve costs one credit and read-only checks are free.
• An API key per account, passed in a header, with memories fully isolated between accounts.

There is no vector index anywhere in it. Retrieval is by key, or by a straightforward text search over keys and values. That is the whole point.

Pricing it as an indie

I priced it the way I would want to be charged: per operation, with a free tier to try it, and no card required to start. New accounts get 100 free operations. After that, credits are bought in flat bundles and do not expire while the account is active. I did not want a monthly subscription that bills you whether you use it or not, because that is exactly the kind of overhead I was trying to avoid in the product itself.

Did it actually work?

The moment it felt real was the first end-to-end test against the live API. One request stored a memory. A second request, in a completely separate call, read it straight back. No database to connect to, no embeddings, no waiting. The value went in and came out, and the whole loop took a single line each way.

# store
curl -X POST https://api.agentram.dev/memory \
  -H "x-api-key: YOUR_KEY" -H "Content-Type: application/json" \
  -d '{"agent_id":"demo","key":"user_language","value":"French"}'

# retrieve
curl "https://api.agentram.dev/memory?agent_id=demo&key=user_language" \
  -H "x-api-key: YOUR_KEY"

Seeing that work confirmed the bet. For the kind of memory most agents actually need, the vector database was never the requirement. It was overhead I had accepted by default.

What I learned

• Reach for the simplest thing that fits the actual need, not the most capable thing in the category. Most agent memory is structured, not semantic.
• Boring infrastructure is a feature. A plain HTTP API over managed Postgres has almost nothing to break, which matters a lot when you are one person.
• Being honest about limits builds trust. AgentRAM does not do semantic search, and saying so plainly is more useful to a developer than pretending it does everything.

If you want the conceptual version of this argument rather than the build story, I wrote a separate guide on when you do and don't need a vector database for agent memory.

An earlier version of this story was first published on my dev.to blog. This is the expanded version on the AgentRAM site.