MemMachine vs Memoria
Long-term memory layer for AI agents — episodic (graph), profile (SQL) and working memory behind Python/TS SDKs, REST and MCP; ships LangChain, LangGraph, CrewAI and LlamaIndex integrations. — versus — Rust memory layer for AI agents with Git-style version control — snapshot, branch, merge and rollback over MatrixOne's copy-on-write engine, plus hybrid vector + full-text retrieval.
Both are long-term memory layers for agents; memmachine splits episodic-graph/profile-SQL/working tiers, Memoria adds Git-style snapshot/branch/merge/rollback and contradiction quarantine on MatrixOne's copy-on-write engine.
| MemMachine | Memoria | |
|---|---|---|
| Stars | 3.3k | 422 |
| Forks | 197 | 53 |
| Language | Python | Rust |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | 3 days ago | 27 days ago |
| Topics | memory | memory |
| Curated connections | 9 | 4 |
MemMachine — the curator's take
Pick it when memory is a product requirement, not a cache: separating episodic (graph) from profile (SQL) from working memory maps to how assistants actually personalize, and the documented LangGraph/CrewAI/LlamaIndex integrations mean you don't write the glue. NOT worth the footprint for a single-user tool — it wants a server plus Neo4j and SQL; a vector store or a JSON file gets a prototype further. Watch the open-core boundary: the managed platform is the business model.
Memoria — the curator's take
Pick it when memory auditability and reversibility matter — you want to branch an agent's memory, roll back a bad write, or trace the provenance of every fact, and you're fine running MatrixOne underneath. Overkill if you just need a simple recall store (memmachine, memmolt) or fully-local files (memanto) — the versioning engine and DB dependency are the cost. Young project, Apache-2.0.