MemQL vs. vector memory for AI agents
There are two common ways to give an AI agent memory. The popular one is vector memory — embed everything and retrieve by similarity (the Mem0 / vector-store approach). The other is what MemQL does: an append-only, time-series graph that treats memory and an agent’s working state as the same queryable data. The key thing to know up front: this isn’t vectors or a graph. MemQL includes vector similarity — the similar() construct does embedding search over the same data — so choosing MemQL doesn’t mean giving up embed-and-retrieve; it means getting it plus time, relationships, provenance, and working state.
Embeddings in a vector index; memories are points in similarity space.
Append-only, time-series graph rows on PostgreSQL + TimescaleDB — with embeddings stored alongside (pgvector). Memories are versioned records with relationships.
The whole product — nearest-neighbour over embeddings is all it does.
Built in, not given up: the similar() DSL construct ranks rows by vector similarity (pgvector), and knowledge domains do classic chunk-embed-retrieve RAG — all on the same engine, not a separate store.
Usually none natively — recency is bolted on as metadata filters.
First-class. Every row is keyed by createdAt; temporal queries and time-decay are built in.
Pure semantic similarity (nearest-neighbour) over embeddings.
similar() for vector similarity, recall() to blend similarity × recency (time-decay) in one query, and exact DSL queries — your pick per call.
None — raw chunks accumulate; nothing distills or expires on its own.
Episodic rows consolidate into durable semantic knowledge on a schedule, so memory distills instead of just piling up.
Flat — memories don't natively reference each other.
Graph — rows relate (a step belongs to a plan, an observation to a step), traversable and typed.
Out of scope — you store an agent's task state elsewhere.
The harness spine — plan, step, observation — is first-class data, so memory and working state share one substrate.
Typically overwrite/replace; little built-in history.
Append-only: nothing is edited in place, so every version and author is preserved — and you can ask what was true at any point in time (asOf), then replay it.
Vector search + metadata filters.
A full DSL — queries, mutations, automations, policies — over the same memory.
You build it — namespaces and any auth live in your app around the store.
Multi-tenant by partition, with per-row authorization built in (test-enforced).
When to use which
Reach for vector memorywhen the job is semantic search over a pile of documents or past messages — “find me things like this” — and you don’t need time, relationships, or durable task state. It’s simple, lighter to run (a library, no database), and great at that one thing.
Reach for MemQL when an agent needs to behavelike it has memory: resume tasks, remember what it tried, reason over time (“what changed since yesterday?”), follow relationships, and let you inspect and replay exactly what it did. And you don’t trade away vector search to get there: MemQL does embedding similarity natively via similar() — it just isn’t only that. It’s the memory and state layer for the whole agent harness.
- Memory & the agent harness — recall(), consolidation, and the plan/step/observation model.
- Read the docs — the data model, the DSL, and the rest.