cortexdb vs engrim
Agent memory plus a knowledge graph with ontology constraints in one SQLite file: pure Go, no server, no embedding model required. Plugins for Claude Code, Codex, dsh and Obsidian. — versus — Local SQLite episodic memory shared across Antigravity, Claude Code, Cursor, Windsurf and Codex: hooks/MCP capture decisions, FTS5+model2vec hybrid recall reloads ~1k tokens per session.
Both are local SQLite memory shared across coding agents via hooks. Engrim stores episodes; CortexDB adds a typed knowledge graph with ontology constraints.
| cortexdb | engrim | |
|---|---|---|
| Stars | 475 | 304 |
| Forks | 27 | 16 |
| Language | Go | Python |
| License | MIT | MIT |
| Last activity | yesterday | 1 months ago |
| Topics | memory, knowledge-graphs | memory, coding |
| Curated connections | 5 | 6 |
cortexdb — the curator's take
Use it when you want local, inspectable memory that is more structured than notes (typed entities, ontology rules, traceable recall) but don't want to run Postgres or Neo4j. Embeds as a Go library, with clients for Rust, Python and Node. Skip it for team-scale shared memory under heavy concurrent writes, or if you just want plain Markdown you can read and edit by hand.
engrim — the curator's take
Use it when you actually switch harnesses mid-project — Gemini in Antigravity in the morning, Claude Code in the afternoon — and want one memory both write to and read from, with `origin_agent` provenance on every entry. `engrim setup` auto-wires hooks, MCP and status lines for whatever it finds under ~/. The retrieval is cheap and offline (FTS5 + static model2vec embeddings, no API), and the deliberate 4k-char 'memory pack' cap keeps it from becoming a second context window. Don't pick it for cross-project or team memory (it is per-project, per-machine), or if you want raw transcript capture rather than curated decisions/facts/feedback. Small project (~200 stars, one maintainer) — expect rough edges.