How does HydraDB think about memory?

In this blog, we will learn how HydraDB frames agent memory as a database problem rather than a prompt problem. We will also see which of its ideas are old database ideas wearing new clothes, and which ones we borrow.

The claim

HydraDB's central argument: when an agent "hallucinates" stale information, the model is usually not the bug. The store is. They split agent failures into four classes:

1. model confabulation (the model's fault)
2. stale-context reads (the store's fault)
3. state-continuity failures across runs (the store's fault)
4. cross-agent corruption when two agents write at once (the store's fault)

Three of four are infrastructure. The fix they propose is the one web engineering made around 2005: take state out of the server and put it in a database with real guarantees. The agent becomes a stateless function; the memory layer owns durability, consistency, and audit.

The three engines in one box

HydraDB describes itself as three storage paradigms fused:

+------------------------------+
|  Git-style temporal graph    |  entities, relationships, versioned edges
+------------------------------+
|  native vector index         |  semantic similarity
+------------------------------+
|  B-tree indexes              |  metadata filters, ordered lookups, time ranges
+------------------------------+

Compare that to a plain vector database, which is only the middle box. A vector database answers "what is similar to this?" and nothing else. It cannot answer "what was true in March?", "who told us this?", or "what changed and why?".

The primitives they ask for

The blog reads like a database textbook, on purpose:

• Read isolation: an agent should read a consistent snapshot, never a half-written state.
• MVCC and optimistic locking: two writers do not silently overwrite each other; the conflict surfaces.
• Event sourcing: an append-only log of every change, replayable.
• Bitemporality: system time and valid time on every assertion.
• Provenance: source utterance, extracting model, confidence.
• Retention: expiry by policy, and crypto-shredding for erasure.

None of these are new. Temporal tables are in the SQL standard. EventStoreDB coined "excision". Crypto-shredding is a GDPR trick. The contribution is saying, out loud, that an agent memory needs all of them.

The write path: resolve references before you embed

Their most practical idea is the "sliding window inference pipeline". A chunk like "she loved it and wants to go back" is useless on its own; the embedding of that sentence points nowhere. HydraDB claims that naive chunking leaves around 40 percent of chunks "semantically invisible" because the pronoun or the entity they depend on lives in another chunk.

So they resolve pronouns, entities, and implicit references at write time, using a window of surrounding turns, and only then embed. This is the same instinct as Mem0's "self-contained, no pronouns" rule and the class extractor's "start with the user's name". Everyone converged on it.

The graph: append-only, versioned edges

Maya --lives_in--> London    system 2025-01-14   valid 2025-01 .. 2026-03
Maya --lives_in--> Paris     system 2026-03-02   valid 2026-03 ..

An update appends a new edge and closes the old one. Concurrent writes that disagree both survive as versions, and a resolver decides later. Every edge carries "why": the reasoning context, sometimes sentiment and situation. They call the retention side a "bio-mimetic decay engine", which is a roadmap name for the episodic decay from the forgetting blog.

The read path: many signals, then rerank

Recall combines semantic similarity, sparse keywords, metadata filters, graph traversal, temporal signals, and entity search, then runs "chunk-level graph expansion" (pull neighbours of the hits) and "triple-tier reranking". Mem0 v3 does three of those signals; HydraDB does more, and reranks harder. Their reported LongMemEval-S score is 90.79 with Gemini 3 Pro as the answer model, with 100 percent on single-session recall and 76.69 on multi-session reasoning, the category everyone finds hardest. They claim sub-200 ms recall.

What is marketing and what is engineering

Be fair about it. The scores are self-reported, on a strong answer model, and not independently reproduced. "Personalized PageRank for memory" and "bio-mimetic decay" are names, not results. The engineering claims underneath are still sound: bitemporal rows, append-only history, provenance, write-time reference resolution, and multi-signal recall.

What we borrow

• The bitemporal row with valid_from, valid_to, created_at, superseded_by, in SQLite, no graph engine.
• source_ids on every memory for provenance and poisoning defense.
• Reference resolution at write time, done by the extractor prompt with the last k turns in view.
• A one-hop expansion at read time: pull the superseded chain and the source turn for the top hits.
• Isolation between the write path and the read path: the async worker writes in its own transaction; readers see committed rows only.

What we skip for now: MVCC across multiple agents writing to the same user, crypto-shredding, and communities. They are real, and they are v2.

Closing

HydraDB's best sentence is its thesis: agent memory is a database problem. Vectors find what is similar; a database remembers what was true, when, according to whom, and what replaced it. Our hybrid takes the vectors from Mem0 and the database discipline from here.